• 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. Deutsche Rentenversicherung Bund, Berlin
  2. SWARCO TRAFFIC SYSTEMS GmbH, Berlin, Unterensingen

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. 25€ (ohne Prime oder unter 29€ zzgl. Versand) - Bestpreis mit Saturn, Vergleichspreis 40€
  2. 18€ (ohne Prime oder unter 29€ zzgl. Versand) - Vergleichspreis 35,99€
  3. (u. a. Transformers 1-4 und Die Tribute von Panem - The Hunger Games 4K für je 12€ und Football...

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
       


Lenovo Thinkpad X1 Fold angesehen (CES 2020)

Das Tablet mit faltbarem Display läuft mit Windows 10X und soll Mitte 2020 in den Handel kommen.

Lenovo Thinkpad X1 Fold angesehen (CES 2020) Video aufrufen
Sicherheitslücken: Microsoft-Parkhäuser ungeschützt im Internet
Sicherheitslücken
Microsoft-Parkhäuser ungeschützt im Internet

Eigentlich sollte die Parkhaussteuerung nicht aus dem Internet erreichbar sein. Doch auf die Parkhäuser am Microsoft-Hauptsitz in Redmond konnten wir problemlos zugreifen. Nicht das einzige Sicherheitsproblem auf dem Parkhaus-Server.
Von Moritz Tremmel

  1. Datenleck Microsoft-Datenbank mit 250 Millionen Support-Fällen im Netz
  2. Office 365 Microsoft testet Werbebanner in Wordpad für Windows 10
  3. Application Inspector Microsoft legt Werkzeug zur Code-Analyse offen

Europäische Netzpolitik: Die Rückkehr des Axel Voss
Europäische Netzpolitik
Die Rückkehr des Axel Voss

Elektronische Beweismittel, Nutzertracking, Terrorinhalte: In der EU stehen in diesem Jahr wichtige netzpolitische Entscheidungen an. Auch Axel Voss will wieder mitmischen. Und wird Ursula von der Leyen mit dem "Digitale-Dienste-Gesetz" wieder zu "Zensursula"?
Eine Analyse von Friedhelm Greis

  1. Mitgliederentscheid Netzpolitikerin Esken wird SPD-Chefin
  2. Nach schwerer Krankheit FDP-Netzpolitiker Jimmy Schulz gestorben

Elektroautos in Tiefgaragen: Was tun, wenn's brennt?
Elektroautos in Tiefgaragen
Was tun, wenn's brennt?

Was kann passieren, wenn Elektroautos in einer Tiefgarage brennen? Während Brandschutzexperten dringend mehr Forschung fordern und ein Parkverbot nicht ausschließen, wollen die Bundesländer die Garagenverordnung verschärfen.
Eine Analyse von Friedhelm Greis

  1. Mercedes E-Econic Daimler elektrifiziert den Müllwagen
  2. Umweltprämie für Elektroautos Regierung verzögert Prüfung durch EU-Kommission
  3. Intransparente Preise Verbraucherschützer mahnen Ladenetzbetreiber New Motion ab

    •  /