Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Dienstag, 09 Juli 2019 | Blog: 2 | No: 43381
Die neuen Ryzen CPUs haben gerade ein Boot-Problem mit diversen Linux-Distros. Und zwar wirft systemd anscheinend einen Haufen Fehler und bricht dann ab. Einen Screenshot findet man bei Phoronix.
Nun bin ich kein Freund von systemd, aber in diesem Fall haben die bloß eine dokumentierte Instruktion namens rdrand aufgerufen, um sich Zufallszahlen von der Hardware geben zu lassen. Dafür ist eigentlich eine Kernelabstraktion da, die systemd hätte verwenden sollen, dann wären sie jetzt nicht "Schuld" gewesen. /dev/urandom oder getentropy sind der bessere Weg.
Aber daraus, eine Instruktion aufzurufen, kann man ihnen keinen Strick drehen.
Das Problem ist schon länger bekannt und scheint irgendein Initialisierungsproblem bei Ryzen zu sein, wo irgendwelche Prozessor-Status-Flags nicht ordentlich gesetzt werden beim Booten. Das ist im Moment alles Spekulation, aber so sieht es aus, und wenn das stimmt, dann ist das mit einem Bios-Update zu reparieren. Da muss man sich aber schon fragen, wieso AMD ihre Validierung so verkackt. rdrand ist eine für eine Menge Sicherheits-Dinge absolut kritische Instruktion. Alle möglichen Krypto-Protokolle und -Verfahren brauchen Zufallszahlen. rdrand setzt ein Flag, ob es erfolgreich war, und liefert dann einen Wert. Bei AMD setzt es das Erfolg-Flag aber liefert immer alle Bits gesetzt zurück im "Zufallswert". Das ist der Worst fucking Case für diese Instruktion. Die meisten weniger guten Krypto-Implementationen werden keine Prüfung haben, ob der Zufall auch wirklich zufällig ist.
Der einzige Grund, wieso das nicht ein Total-Desaster ist gerade, ist dass eh niemand dem ursprünglichen Intel-rdrand vertraut hat, weil die NSA gerade ein Snowden-Vertrauensproblem hatte und der Zufallszahlengenerator der offensichtliche Geheimdienst-Angriffsvektor auf Open Source Kryptosysteme ist. Daher nimmt der Kernel das auch nur zusätzlich zu anderen Zufallsquellen in /dev/urandom. Hätte systemd also den Zufall vom Kernel bezogen, wäre alles gut gewesen. Auf der anderen Seite hätten wir dann vielleicht gar nicht von diesem Bug gehört. Insofern bin ich systemd doch dankbar. Und bin froh, dass meine Distro nicht auf systemd basiert :-)
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Dienstag, 09 Juli 2019 | Blog: 2 | No: 43381
Screenshot findet man bei Phoronix
Nun bin ich kein Freund von systemd, aber in diesem Fall haben die bloß eine dokumentierte Instruktion namens rdrand aufgerufen, um sich Zufallszahlen von der Hardware geben zu lassen. Dafür ist eigentlich eine Kernelabstraktion da, die systemd hätte verwenden sollen, dann wären sie jetzt nicht "Schuld" gewesen. /dev/urandom oder getentropy sind der bessere Weg.
Aber daraus, eine Instruktion aufzurufen, kann man ihnen keinen Strick drehen.
Das Problem ist schon länger bekannt und scheint irgendein Initialisierungsproblem bei Ryzen zu sein, wo irgendwelche Prozessor-Status-Flags nicht ordentlich gesetzt werden beim Booten. Das ist im Moment alles Spekulation, aber so sieht es aus, und wenn das stimmt, dann ist das mit einem Bios-Update zu reparieren. Da muss man sich aber schon fragen, wieso AMD ihre Validierung so verkackt. rdrand ist eine für eine Menge Sicherheits-Dinge absolut kritische Instruktion. Alle möglichen Krypto-Protokolle und -Verfahren brauchen Zufallszahlen. rdrand setzt ein Flag, ob es erfolgreich war, und liefert dann einen Wert. Bei AMD setzt es das Erfolg-Flag aber liefert immer alle Bits gesetzt zurück im "Zufallswert". Das ist der Worst fucking Case für diese Instruktion. Die meisten weniger guten Krypto-Implementationen werden keine Prüfung haben, ob der Zufall auch wirklich zufällig ist.
Der einzige Grund, wieso das nicht ein Total-Desaster ist gerade, ist dass eh niemand dem ursprünglichen Intel-rdrand vertraut hat, weil die NSA gerade ein Snowden-Vertrauensproblem hatte und der Zufallszahlengenerator der offensichtliche Geheimdienst-Angriffsvektor auf Open Source Kryptosysteme ist. Daher nimmt der Kernel das auch nur zusätzlich zu anderen Zufallsquellen in /dev/urandom. Hätte systemd also den Zufall vom Kernel bezogen, wäre alles gut gewesen. Auf der anderen Seite hätten wir dann vielleicht gar nicht von diesem Bug gehört. Insofern bin ich systemd doch dankbar. Und bin froh, dass meine Distro nicht auf systemd basiert :-)
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
