Login
Newsletter
Werbung

Thema: Linux-Kernel 5.3 freigegeben

22 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ghul am Mo, 16. September 2019 um 11:41 #

Mit einer IPv6 oder einer (externen) IPv4 Adresse?

Kurz welche Datenpakete versendet euer Router an das Netz außerhalb eures LANs am meisten, IPv4 Pakete oder IPv6 Pakete?

0
Von HardwareAmateur am Di, 17. September 2019 um 06:53 #

...machte Torvalds eine Optimierung des ext4- Dateisystems rückgängig. [...]. Manche Systeme konnten beim Booten nicht mehr genug Entropie sammeln und hingen daher, da der sichere Zufallsgenerator nicht initialisiert werden konnte.
Da hat Torwalds der Linux-Welt wohl den Allerwertesten gerettet ;)
Ohne ein zuverlässiges /dev/random keine Netzwerkverschlüsselung. Der Entropie-Pool ist scheinbar eine unterschätzte Herausforderung. Auch AMD's neuer Ryzen 3000 hatte ein schwerwiegendes Problem mit dem Zufallszahlengenerator, so dass einige Kernel nicht mehr booten konnten.

  • 0
    Von Verfluchtnochmal_5987108 am Di, 17. September 2019 um 09:38 #

    Erstens geht es nicht um /dev/random sondern um syscalls und zweitens darum dass deine Kiste gar nicht erst gebootet hätte wenn irgendein Trottel meint kryptografisch sichere Zufallszahlen für etwas zu verschwenden dass sie nicht braucht und das möglichst früh im Bootvorgang damit ja gute Chancen bestehen endlos zu blocken womit sich der Zustand auch nicht mehr ändert

    1
    Von klopskind am Di, 17. September 2019 um 12:06 #

    Das darunterliegende Problem ist so vielfältig, dass die beteiligten Entwickler sich bisher uneinig sind, wie damit umzugehen ist. Da es so knapp vor dem Veröffentlichungstermin von Linux 5.3 entdeckt wurde, hat sich Linus dazu entschieden, die Optimierung von ext4, die das Fass in einem ganz anderen Subsystem (crypto) zum Überlaufen brachte, vorerst (d.h. wahrscheinlich für Linux 5.3.y) zurückzunehmen, damit dieser Fehler nicht zum Tragen kommt. Der eigentliche "Bug" besteht weiterhin.
    Quelle [1]

    Dabei geht es um die kritische Phase beim Booten bevor der CRNG des Linux-crypto-Subsystems initialisiert wurde. Dafür muss zunächst eine gewisse Menge Entropie "bemessen" (kann per Definition nur anhand eines Schätzers abgeschätzt werden) und aufbereitet werden (derzeit 512 Byte?). Bis dahin blocken die Zugriffe auf den Pool z.B. via /dev/random (random(4)), welches die Entropie sogar "verbraucht" also den Pool erschöpft (unter Kryptologen übrigens ein äußerst strittiges Konzept), oder getrandom(2). /dev/urandom setzt in diesem lediglich eine Warnung ins Kernel-Log ab.

    Das ist besonders kritisch bei Systemen, bei denen das "Sammeln" & "Schätzen" der Entropie schwierig bzw. die Menge der "geschätzten" Entropie begrenzt ist und von denen gleichzeitig erwartet wird, dass sie verlässlich und konsistent zügig booten statt minuten- bis stundenlange Hänger zu haben.

    Um einerseits zu wissen, welche Systeme davon nun (am ehesten) betroffen sind, muss man verstehen, welche Entropiequellen dem Kernel zur Verfügung stehen. So "sammelt" Linux Entropie etwa anhand von Hardware Ereignissen wie Interrupts, Benutzereingaben (HID: z.B. Tastatur, Maus), CPU-Zyklenzähler (Unterstützung architekturabhängig) oder eigens dafür entwickelte Komponenten wie Hardware-RNGs in TPM, USB-Sticks, RDSEED/RDRAND (beschränkt auf x86 und Linux nutzt diese Instruktion standardmäßig nicht) etc.
    Betroffen wären also z.B. Embedded-Geräte, bestimmte Architekturen, Server und virtuelle Maschinen, oder generell Hardware, die tendenziell weniger Interrupts erzeugt (z.B. SSDs im Vergleich zu HDDs). Es gibt aber sicher noch mehr.
    Quelle [2] via [3], [4], [5]

    Andererseits werden auch inzwischen teils viel mehr Zufallszahlen während des Bootens verwendet, insbesondere wegen der Anforderung einiger Geräte, sofort im Netzwerk/Internet hängen zu müssen, um Ihre erdachte Funktion tatsächlich erfüllen zu können. So wäre da bspw. ASLR, systemd-interne Hashtabellen, UUID-Generierung, Generierung temporärer Dateien, Swap-Verschlüsselung mit Zufallsschlüssel je Start, Portrandomisierung, Randomisierung der TCP sequence number, DHCP-Klient, DNS oder SSH-Schlüsselgenerierung, Login-Manager wie GDM, etc.
    Quellen [1], [6], [7], [8]

    Einige Entwickler im "user space" tragen also Ihren Teil zu dem Problem bei. Die Frage ist, ob das tatsächlich immer nötig ist, so früh auf so viel Entropie angewiesen zu sein. Und auch die Hersteller der Geräte müssen diese solide ausstatten, damit die steigenden Anforderungen der Entwickler (und damit der Anwendungen und Nutzer) erfüllt werden.

    Tools wie rng-tools oder havaged sind nur Krücken und werden von einigen Sicherheitsforschern sehr kritisch beäugt.
    Quellen [9], [10]

    Jedenfalls ist die Lage ziemlich verzwickt, denn das Anwendungs-/Anforderungs-Spektrum von Linux ist inzwischen so groß, dass keine simple Lösung ausreicht, um das ganze Spektrum abzudecken. Standardmäßig verwendet Linux kein random seed file, wie etwa die BSDs es seit einiger Zeit tun. Hier spielen die BSDs ihren Vorteil aus, das ganze Basissystem zu kontrollieren und nicht nur den Kernel.
    Immerhin bietet systemd inzwischen einen optionalen Dienst (systemd-random-seed), der das entsprechend umsetzt. Auch systemd-boot bietet hier ein Lösung an, beschränkt sich aber nur auf EFI-Systemen.
    Quellen [11], [12], [13]

    Zudem ist Linux RNG relativ langsam ggü. anderen Betriebssystemen. Es gab da mal einen Vortrag auf einer BSD-Konferenz, der Linux, FreeBSD und Windows (oder macOS?) verglichen hat. Leider finde ich den gerade nicht mehr. :(

    Die Diskussionskultur in [1] finde ich teils sehr verbesserungswürdig. Wie unsachlich und unstrukturiert das Problem teils diskutiert und erörtert wird, ist beschämend - insbesondere in Anbetracht bereits existierender Lösungen. Da werden wild Annahmen aufgestellt, von Ideen um ernste Warnungen und Fehlermeldung vor den Anwendern zu verstecken fantasiert, spezielle Awendungsfälle ersonnen und gleichzeitig andere gänzlich ausgeblendet, allein um das jeweilig subjektive "Problem" zu benennen, natürlich beim Anderen.
    Linux, die Linux-Distributionen und systemd bzw. die "Distro-Middleware" der Wahl haben hier noch viel zu tun!

    • 0
      Von ac am Di, 17. September 2019 um 22:53 #

      Sehr gute Zusammenfassung. Vielen Dank.

      0
      Von 1ras am Fr, 20. September 2019 um 20:18 #

      Swap-Verschlüsselung mit Zufallsschlüssel je Start

      Ob das so eine gute Idee ist da bin ich seit heute auch am zweifeln. Mir ist erst heute mein Rechner nicht hochgefahren, weil Systemd Swap nicht einhängen konnte, welches genau auf diese Weise verschlüsselt wird. Nach 2 Minuten sinnlosem warten während Systemd die Zeit hochzählte, habe ich dann die Reißleine gezogen und nochmal neu gebootet. Ging dann auch wieder. Nein, kein 5er Kernel. Muss das Verhalten mal weiter beobachten.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Sep 2019 um 20:19.
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung