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 17. September 2019, 11:55 Uhr, Hanno Böck

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.

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.

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.