• IT-Karriere:
  • Services:

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. Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), München
  2. CureVac AG, Tübingen bei Stuttgart

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.

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


Anzeige
Top-Angebote
  1. 129€ (Bestpreis mit Saturn. Vergleichspreis 159,99€ + Versand)
  2. (u. a. Total War: Warhammer II für 24,99€, Halo Wars 2 (Xbox One / Windows 10) für 10,49€ und...
  3. 1,99€
  4. (u. a. Ecovacs Robotics Deebot Ozmo 905 heute für 333€, Philips 58PUS6504/12 für 399€, JBL...

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...


Folgen Sie uns
       


Command and Conquer Remaster - Test

Nach Desastern wie Warcraft 3: Reforged ist die gelungene Remastered-Version von C&C eine echte Erfrischung.

Command and Conquer Remaster - Test Video aufrufen
    •  /