Abo
  • IT-Karriere:

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. Deloitte, verschiedene Standorte
  2. MACH AG, Berlin, Lübeck

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.



Anzeige
Hardware-Angebote
  1. (Samsung 970 EVO PLus 1 TB für 204,90€ oder Samsung 860 EVO 1 TB für 135,90€)
  2. täglich neue Deals bei Alternate.de
  3. 99,00€
  4. 69,90€ (Bestpreis!)

Mavy 18. Sep 2019 / Themenstart

wurstberechnung und käsequantenmechanik .. alles Klar :D

Mavy 18. Sep 2019 / Themenstart

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

Floyddotnet 17. Sep 2019 / Themenstart

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

Kommentieren


Folgen Sie uns
       


Minecraft Earth - Gameplay

Minecraft schafft den Sprung in die echte-virtuelle Welt: In Minecraft Earth können Spieler direkt in der Nachbarschaft prächtige Gebäude aus dem Boden stampfen und gegen Skelette kämpfen.

Minecraft Earth - Gameplay Video aufrufen
Atari Portfolio im Retrotest: Endlich können wir unterwegs arbeiten!
Atari Portfolio im Retrotest
Endlich können wir unterwegs arbeiten!

Ende der 1980er Jahre waren tragbare PCs nicht gerade handlich, der Portfolio von Atari war eine willkommene Ausnahme: Der erste Palmtop-Computer der Welt war klein, leicht und weitestgehend DOS-kompatibel - ideal für Geschäftsreisende aus dem Jahr 1989 und Nerds aus dem Jahr 2019.
Ein Test von Tobias Költzsch

  1. Retrokonsole Hauptverantwortlicher des Atari VCS schmeißt hin

Alexa: Das allgegenwärtige Ohr Amazons
Alexa
Das allgegenwärtige Ohr Amazons

Die kürzlich angekündigten Echo-Produkte bringen Amazons Sprachassistentin Alexa auf die Straße und damit Datenschutzprobleme in die U-Bahn oder in bisher Alexa-freie Wohnzimmer. Mehrere Landesdatenschutzbeauftragte haben Golem.de erklärt, ob und wie die Geräte eingesetzt werden dürfen.
Von Moritz Tremmel

  1. Digitaler Assistent Amazon bringt neue Funktionen für Alexa
  2. Echo Frames und Echo Loop Amazon zeigt eine Brille und einen Ring mit Alexa
  3. Alexa Answers Nutzer smarter Lautsprecher sollen Alexa Wissen beibringen

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

    •  /