Linux-Kernel: Bootprobleme wegen fehlender Zufallszahlen

Eine Optimierung bei Dateisystemoperationen im Linux-Kernel führt zu blockierten Bootvorgängen auf manchen Systemen. Schuld daran sind Userspace-Programme, die zuverlässige Zufallsdaten wollen, bevor diese bereitstehen.

Artikel veröffentlicht am ,
Zufallszahlen korrekt zu implementieren, ist trickreich - wie die Kernelentwickler wieder einmal feststellen mussten.
Zufallszahlen korrekt zu implementieren, ist trickreich - wie die Kernelentwickler wieder einmal feststellen mussten. (Bild: Liam Quin/Wikimedia Commons/CC-BY 3.0)

Im jüngsten Release 5.3 des Linux-Kernels wurde eine Änderung bei Dateisystemoperationen in letzter Minute zurückgenommen. Linus Torvalds erläutert in der Release-Ankündigung, dass die Änderung selbst nicht fehlerhaft war, aber indirekt dazu führte, dass Anwendungen im Userspace nicht mehr korrekt arbeiteten. Der Hintergrund: Durch die Änderung wurde weniger Entropie durch Festplattenoperationen erzeugt, was dazu führte, dass der Zufallszahlengenerator später initialisiert wird.

Stellenmarkt
  1. SAP Basis Berater (m/w/x)
    über duerenhoff GmbH, Raum Berlin
  2. (Senior) IT Consultant IT Vendor Management Application Development & Maintenance (m/w/d)
    ALDI International Services SE & Co. oHG, Mülheim an der Ruhr
Detailsuche

Seit einigen Jahren besitzt Linux einen Syscall namens getrandom(). Dieser Befehl, mit dem eine Anwendung Zufallszahlen vom Kernel abfragen kann, sollte Probleme mit den bisherigen Interfaces beheben. Traditionell besitzt Linux zwei virtuelle Devices - /dev/random und /dev/urandom -, aus denen Anwendungen Zufallszahlen auslesen können.

Blockieren oder nicht blockieren?

Aus /dev/urandom kann man immer Zufallszahlen auslesen, man erhält aber keine Garantie, dass es sich um Zufallszahlen hoher Qualität handelt. Das ist insbesondere kurz nach dem Booten riskant und kann beispielsweise dazu führen, dass Software, die automatisiert beim Booten kryptographische Schlüssel erzeugt, auf verschiedenen Systemen identische geheime Schlüssel nutzt. Das /dev/random-Interface liefert nur dann Zufallszahlen, wenn der interne Status des System-Zufallszahlengenerators permanent genug Entropie erhält, ansonsten blockiert das Auslesen.

In vielen Fällen will man weder das eine noch das andere. Wenn der Zufallszahlengenerator einmal mit genügend Entropie initialisiert ist, besteht kein Grund mehr, die Ausgabe zu blockieren. Daher wurde getrandom() eingeführt; das Standardverhalten der Funktion ist, nur dann zu blockieren, wenn der Zufallszahlengenerator nach dem Booten noch nicht mit genügend Entropie initialisiert wurde.

Golem Akademie
  1. Microsoft 365 Administration: virtueller Drei-Tage-Workshop
    01.-03.06.2022, Virtuell
  2. Einführung in Unity: virtueller Ein-Tages-Workshop
    21.06.2022, Virtuell
Weitere IT-Trainings

Wie sich nun herausstellte, gibt es Anwendungen, die getrandom() beim Starten verwenden und nicht damit rechnen, dass der Zufallszahlengenerator noch nicht initialisiert sein könnte. Ein Beispiel dafür ist Xorg, das beim Starten einen Zufallswert für das sogenannte MIT-Magic-Cookie verwendet. In der Konsequenz kann das dazu führen, dass der Bootvorgang für längere Zeit blockiert wird.

Optimierung reduziert Festplattenzugriffe

Die Änderung, die nun zu den Problemen mit getrandom führte, war eine Optimierung im Ext4-Dateisystem. Diese führte dazu, dass der Kernel beim Booten weniger Festplattenzugriffe benötigte. Nun ist es so, dass Festplattenzugriffe eine der Quellen für Entropie des Linux-Kernels sind. Linux nutzt etwa die Zeit, die ein Zugriff dauert, um den internen Zufallszahlengenerator zu initialisieren.

Die Folge: Weniger Festplattenzugriffe beim Booten führten dazu, dass der Zufallszahlengenerator nicht früh genug initialisiert wurde - und eine ganze Reihe von Systemen beim Booten stehenblieben.

Die Optimierung in Ext4 wurde nun vorerst zurückgenommen. Wie man aber grundsätzlich mit dem Problem umgehen soll, darüber ist eine lange Diskussion auf der Kernel-Mailingliste entbrannt. Ein Vorschlag sah sogar vor, dass getrandom() künftig einfach nicht mehr blockieren und sich so wie /dev/urandom verhalten sollte. Doch das würde den Sinn des Interface komplett untergraben und könnte wiederum zu schweren Sicherheitslücken führen.

Ein Vorschlag von Linus Torvalds selbst sieht vor, dass getrandom() weiterhin blockiert, aber nur für eine begrenzte Zeit und dann einen Fehler zurückgibt. Beim ersten Mal würde der Aufruf für 15 Sekunden blockiert, bei späteren Aufrufen kürzer. Insgesamt soll es maximal 30 Sekunden Wartezeit geben. Torvalds hofft, dass das einerseits lange genug ist, dass das Problem bemerkt und gefixt wird, dass es aber andererseits nicht so lange ist, dass man von einem fehlgeschlagenen Bootvorgang ausgeht.

An anderer Stelle wurde auch diskutiert, ob und wie Bootmanager bei dem Problem abhelfen können. So besteht die Möglichkeit, dass ein System beim Herunterfahren Zufallsdaten speichert, die beim Booten wieder in den Kernel-Entropiepool eingelesen werden. Doch die Details sind komplex, wie etwa aus einer Mail von Systemd-Entwickler Lennart Pottering hervorgeht. Probleme ergeben sich etwa, wenn eine VM geklont wird und dann auf zwei Systemen dieselbe Entropie als zuverlässig in den Kernel-Entropiepool eingespeist wird.

Wie die Lösung letztendlich aussehen wird, ist noch unklar. Es zeigt sich aber wieder einmal, welche Herausforderung die korrekte Implementierung von Zufallszahlengeneratoren beinhaltet.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Mavy 18. Sep 2019

wurstberechnung und käsequantenmechanik .. alles Klar :D

Mavy 18. Sep 2019

Echtes Random ist halt schwer von einem System zu bekommen da im Idealfall jeder Prozess...

Floyddotnet 17. Sep 2019

getrandom() ist ein Psydozufallszahlengenerator wie /dev/urandom der mit hoher Entropie...



Aktuell auf der Startseite von Golem.de
Halbleiter & SMIC
Chip-Nachfrage für Smartphones und PC fällt "wie ein Stein"

Chinesische Kunden von SMIC haben volle Lager und ordern weniger Chips. Andere Halbleiter sollen den Einbruch auffangen.

Halbleiter & SMIC: Chip-Nachfrage für Smartphones und PC fällt wie ein Stein
Artikel
  1. Google: Russland will Youtube aus Selbstschutz nicht blockieren
    Google
    Russland will Youtube aus Selbstschutz nicht blockieren

    Die zahlreichen Drohungen der russischen Zensurbehörde zur Blockade von Youtube werden wohl nicht umgesetzt. Die Auswirkungen wären zu stark.

  2. Arclight Rumble: Wegen Warcraft Mobile sollte sich Blizzard selbst verklagen!
    Arclight Rumble
    Wegen Warcraft Mobile sollte sich Blizzard selbst verklagen!

    Golem.de hat es gespielt: Arclight Rumble entpuppt sich als gelungenes Mobile Game - aber wie ein echtes Warcraft fühlt es sich nicht an.
    Von Peter Steinlechner

  3. Biontech: Mainz kann 365-Euro-ÖPNV-Ticket dank Corona einführen
    Biontech
    Mainz kann 365-Euro-ÖPNV-Ticket dank Corona einführen

    In Mainz ist Biontech beheimatet, was die Steuereinnahmen explodieren lässt. Mit dem Geld wird nun ein 365-Euro-Jahresticket für Schüler und Azubis finanziert.

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • PS5 jetzt bestellbar • Cyber Week: Bis zu 900€ Rabatt auf E-Bikes • MindStar (u. a. Intel Core i9 529€, MSI RTX 3060 Ti 609€) • Gigabyte Waterforce Mainboard günstig wie nie: 480,95€ • Razer Ornata V2 Gaming-Tastatur günstig wie nie: 54,99€ • AOC G3 Gaming-Monitor 34" 165 Hz günstig wie nie: 404€ [Werbung]
    •  /