Linux-Abstürze: Fehlerhafter Zufallsbefehl auf neuen und alten AMD-CPUs

Einige Linux-Systeme booten auf AMDs neuen Ryzen-Prozessoren nicht und haben auf alten APUs Probleme mit dem Suspend. Der Grund ist eine fehlerhafte Implementierung des Zufallszahlengenerators der CPU, den Systemd aufruft. Systemd arbeitet aber völlig korrekt, das Problem liegt in der CPU.

Artikel veröffentlicht am 9. Juli 2019, 15:43 Uhr, Hanno Böck/Sebastian Grüner

Fehler beim Zufall: Einige AMD-Prozessoren implementieren den rdrand-Befehl falsch. (Bild: Diacritica, Wikimedia Commons/CC-BY-SA 3.0)

Ein Bug in AMD-CPUs führt zu Abstürzen beim Booten von manchen Linux-Distributionen. Schuld daran ist ein Fehler bei der rdrand-Funktion, einem Prozessorbefehl zur Erzeugung von Zufallszahlen. Neuere Versionen von Systemd rufen diesen Befehl auf.

Mit dem rdrand-Befehl kann eine Anwendung von der CPU eine Zufallszahl anfordern. Der Befehl gibt dabei eine Zahl zurück und meldet außerdem, ob der Befehlsaufruf erfolgreich war. Das Problem auf AMDs Ryzen 3000: Der Prozessor gibt statisch die Zahl -1 als Zufallswert zurück, meldet aber gleichzeitig, dass der Aufruf erfolgreich war.

Systemd ruft rdrand auf und verlässt sich auf korrektes Verhalten

Neuere Versionen von Systemd rufen die rdrand-Instruktion auf und stürzen ab, wenn mehrfach keine Zufallszahlen zurückgegeben werden. Eingeführt wurde das im Juli 2018 und ist dann in die Systemd-Version 240 eingeflossen. Das erklärt auch, warum das Problem nur mit bestimmten aktuellen Linux-Distributionen auftaucht. Das jüngste Ubuntu 19.04 etwa nutzt Systemd 240 und ist betroffen, die ältere Version 18.10 nutzt Systemd 239 und stürzt nicht ab.

Doch auch wenn das Problem erst durch Systemd ausgelöst wird, der Fehler liegt eindeutig in der CPU selbst. Denn Systemd verwendet die Funktion völlig korrekt und geht davon aus, dass es einen Zufallswert erhält, wenn der Prozessor ein erfolgreiches Ausführen des Befehls meldet.

Wir haben das Verhalten der AMD Ryzen-CPUs getestet und konnten den Bug für die aktuelle 3000er-Generation nachvollziehen. Beim Aufruf eines kleinen Test-Programms, das nur die rdrand-Funktion aufruft und das Resultat ausgibt, erhielten wir bei mehreren Aufrufen immer den codierten Wert von -1 und eine Bestätigung, dass der Befehl erfolgreich ausgeführt wurde. Auf älteren Generation der Zen-Architektur, also den Ryzen 1000 und 2000, tritt der Fehler nicht auf und der Befehl liefert wie gewünscht eine Zufallszahl.

Probleme auch mit alten AMD-CPUs

Ein älterer Kernel-Bug weist darauf hin, dass das Problem auch in älteren AMD-Prozessoren auftauchen kann. Laut diesem Bugreport, der bereits 2014 erstellt wurde, gab es Probleme mit dem rdrand-Befehl bereits bei einem Prozessor aus der Jaguar-Reihe von AMD. Auch die initiale Fehlermeldung im Bugtracker von Systemd verweist auf ältere APUs von AMDs Carrizo-Reihe mit Puma-Architektur. Bei den älteren CPUs betrifft der durch Systemd ausgelöste Fehler den Meldungen zufolge jedoch nicht direkt den Boot, sondern zunächst wohl nur den Ruhezustand (Suspend).

Offenbar blieb das Problem aber lange unentdeckt, da nur wenige Programme rdrand direkt aufrufen. Üblicherweise verwenden Anwendungsprogramme die Zufallsfunktionen des Kernels wie /dev/urandom oder den getrandom-Syscall. Der Kernel verwendet selbst zwar auch rdrand, er nutzt dessen Ausgabe aber nur als eine von vielen Zufallsquellen, um den Zufallszahlengenerator des Betriebssystems zu betreiben. Das hat auch den Grund, dass einige Entwickler nicht darauf vertrauen, dass die CPU korrekte Zufallszahlen liefert.

Die Probleme fallen wohl erst jetzt in größerem Maße auf, weil Systemd den rdrand-Befehl direkt nutzt. Inzwischen ist in Systemd ein Workaround eingeführt worden, der dazu führt, dass unsinnige Werte (0 oder -1) vom Zufallszahlengenerator verworfen werden.

Besonders kurios an dem Fehler ist, dass der Befehl auf den älteren Ryzen-Chips wie gewünscht funktioniert und damit auch aktuelle Linux-Distribution mit dem aktuellen Systemd problemlos booten. Sowohl auf den Vorgänger-Chips als auch auf den Nachfolgern treten jedoch die beschriebenen Probleme auf. Ein korrekter Fix wäre vermutlich über den CPU-Microcode möglich, dieser müsste aber direkt von AMD kommen.