Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsRyzen 3000: BIOS-Update gegen Probleme mit Linux und Destiny 2
Ich finde es etwas besorgniserregend, das so ein grober Fehler vorab nicht bereits beachtet wurde.
Ob in der neuen Plattform hier und da der Hase begraben liegt?
Man will es nicht hoffen!
ist mit sicherheit aufgefallen, wurde aber als weniger wichtig erachtet, linux user gibts ja kaum, kann man später noch fixxen, linux user sinds doch eh nicht anders gewohnt und basteln gerne
ist mit sicherheit aufgefallen, wurde aber als weniger wichtig erachtet, linux user gibts ja kaum, kann man später noch fixxen, linux user sinds doch eh nicht anders gewohnt und basteln gerne
Viele Dinge bekommen sogenannte UUIDs (universal unique identifier) Schon der Bootvorgang als Solches bekommt jedesmal eine UUID. Ein recht gut funktionierender "Trick" ist da einfach Zufallszahlen zu nutzen. In Sachen simpler Code, Performance und Fehleranfälligkeit ist das sogar eine recht gute Lösung. Als Zufallsquellen hat man zum Systemstart jedoch nicht all zu viel. Der Linux Kernel selbst benötigt einige Zeit [1] bis er der Meinung ist Zufall liefern zu können. Darauf wollen die Entwickler von Systemd nicht warten. Da die Anforderungen an den gelieferten Zufall nicht all zu hoch ist (ist ja keine Crypto) nimmt man den Zufall den moderne CPUs liefern können.
Dumm ist an der Stelle, dass die AMD CPUs immer den Wert -1 liefern und gleichzeitig aber anzeigen, dass der CPU-Befehl korrekt ausgeführt wurde (carrier flag). SystemD prüft den c-flag und kontrolliert ob UUIDs mehrfach vergeben wurden. Der c-flag ist korrekt, die UUIDs sind aber immer -1, also versucht systemd erneut Zufall zu holen und schon haben wir unsere Endlosschleife ins Verderben.
[1] Bei einigen Systemen reden wir hier von mehreren Sekunden bis Minuten
Hier vergessen viele das wir immer noch Skylake als Architektur haben. Das ist mittlerweile recht eingespielt mit den Herstellern, ob das nun 4 oder 8 Kerne sind, ist da recht egal.
Man sollte wohl einige nochmal daran erinnern wie der Skylake Launch verlief. Eine Katastrophe, auf einigen Boards wurden sogar SATA Anschlüsse (auf dauer) deaktiviert, wegen groben Fehlern. Da ist das hier alles Kinderkacke.
Die Zufallszahl ist z.B. für verschlüsselte Verbindungen wichtig. Auf embedded Controllern ohne angeschlossene LAN Kabel und Echtzeituhr hab ich beobachtet, dass der SSH Dienst verzögert startet, weil noch nicht genug Entropie für den Zufallsgenerator gesammelt wurde.
Da werden normalerweise verschiedene Quellen genutzt: Netzwerkpakete, Uhrzeit, Tastatureingaben, etc.
Der Zufall aus der CPU den man über RDrand bekommt vertraut man eigentlich nicht und nutzt ihn deswegen garnicht oder nur als einen vieler Zufallsquellen. Begründet wird das u.a. damit, dass die CPUs nicht vertrauenswürdig sind an der Stelle (AMD hat es bewiesen ).
Naja und systemd nutzt wenn es um Sicherheit geht auch nicht RDrand sondern fragt brav /dev/urand
Ergänzung ()
Denniss schrieb:
Systemd nutzt den generator der CPU lediglich um beim Start eindeutige UUIDs an Hardwarekomponenten zu vergeben. Man hätte natürlich auch die dafür vorgesehen Funktion des Kernels nutzen können aber das war den Programmierern wohl zu einfach/umständlich.
Der Kernel braucht schlicht ewig bis er der Meinung ist ausreichend Entropie gesammelt zu haben. Damit zieht es den Bootvorgang in die Länge. Deswegen wurde eine ausreichend gute Zufallsquelle gewählt die etwas bessere Performance liefert.
Die AMD CPUs bauen an der Stelle halt einfach Mist und setzten das "ich hab Mist gebaut" Bit dann auch noch falsch.
Das rrand auf AMD Systemen nicht zuverlässig läuft, ist nicht erst seit Ryzen bekannt. Nur wechselten die systemd Entwickler trotz des Wissens auf die Funktion. AMD hätte das bisher natürlich fixen müssen. Ist auch der Grund, warum ältere SystemD-Versionen liefen.
Anstatt also einen Workaround zu benutzen, gibt es folgende Begründung:
In general: we have to trust that CPUs work. If they don't we are fucked.
Nich falsch verstehen, der Launch ist alles andere als glatt. Aber Fehler gabs und wirds immer geben. Wichtiger ist, daß man das per Patch beheben kann und kein Hw-Fehler ist.
Das ist genauso ein Unsinn wie Spectre, Meltdown, jucken einen auch nicht. Bei diesem Bug ist der Zufallszahlgenerator unprediktiv schlecht. Zufall wird für viele Dinge benutzt, wie Sessionkeys bei TLS, etc. Machst du Homebanking? Denk mal drüber nach. Das geht alles kaputt, wenn Zufall erratbar ist.
Ned Flanders schrieb:
Kaum zu glauben, das AMDs QC nicht aufgefallen sein soll, das systemD distros auf ihren neuen CPUs nicht starten.
Ältere Versionen von systemd zeigen kein Problem, nur die neuesten. Ein Ubuntu 18.04 läuft, ein 19.04 nicht. 18.04 ist das, was in Unternehmen interessant ist.
Transistor 22 schrieb:
Testen die die CPUs nicht umfangreich? Auch wenn es für die meisten Gamer nicht schlimm ist, aber auf vielen Servern läuft Linux und wenn auf den Epic Servern kein Linux läuft, ist das für AMD ein schwerer Image Schaden.
Egal was man tut, bei komplexen Produkten sind immer Bugs nach Release da. Das patched man dann eben. Wichtig ist wie sich der Hersteller verhält, und wie schnell und ob er wirkungsvoll liefert. Gamer sind übrigens auch nur semiinteressant. Der Servermarkt, da liegen die grossen Summen auf dem Tisch und die mögliche Profitmarge.
Das ist völlig irrelevant. Wenn bei deinem Auto die Sitzheizung defekt ist, gibst du dich auch nicht mit der Antwort "im Sommer braucht eh niemand eine Sitzheizung" des Händlers zufrieden. Der Prozessor bietet die Funktion und demnach hat diese auch gefälligst zu funktionieren. Poettering ist hier kein Fehler anzukreiden, man kann von systemd halten was man will, aber in diesem speziellen Fall ist der gute Hardliner unschuldig. Der Fehler liegt völlig eindeutig bei AMDs Prozessoren. Das Update ist demnach auch nötig gewesen.
Da hat Lennart doch aber recht. Als Programmierer muss man sich drauf verlassen, dass CPU Befehle sich entsprechend ihrer Definition verhalten. Im Zweifelsfall sieht der einfachste Fix im Microcode der AMD CPUs dann auch so aus, dass sie das C-Flag einfach immer auf 0 setzen und RDrand garnicht geht. Aber wenigstens geht es erkennbar nicht und systemd würde entsprechend (richtig) darauf reagieren können.
Er hat grundsätzlich Recht. Nur wenn ich weiß, das die Funktion u.U. nicht funktioniert, dann kann ich sie einfach nicht einsetzen. Aber genau das machten sie trotzdem.
wo ist das problem?
der aufruf liefert -1.
die cpu sagt, es hat funktioniert.
=> das programm soll mit -1 weitermachen. is halt blöd, wenns immer der selbe wert ist, aber das kann nun mal passieren, wenn man zufallszahlen haben will. damit war zu rechnen.
Bei Zen/Zen+ funktioniert es seltsamerweise. Da ist man eben davon ausgegangen, dass es bei Zen2 genau so ist.
Heute kommt auch keiner mehr auf die Idee, einen Fix für den FDIV-bug in seine Bootroutine zu implementieren.
Was sagt der Postbote, wenn jedes Haus der Straße dieselbe Hausnummer hat wie du?
Son scheiß, genau.
Lese die Beiträge von Piktrogramm nochmal durch, der hat es auf den Punkt gebracht.
Systemd nutzt den generator der CPU lediglich um beim Start eindeutige UUIDs an Hardwarekomponenten zu vergeben. Man hätte natürlich auch die dafür vorgesehen Funktion des Kernels nutzen können aber das war den Programmierern wohl zu einfach/umständlich.
@yummycandy
Willkommen in der Softwareentwicklung, kein Programmierer schreibt Software so, dass alle etwaigen Bugs / Errata aller x86, ARM, MIPS, Power, Sparc, Alpha, Ra-Risc, IA64, m68k, MicroBlaze, Xtensa, AVR32, RiscV CPUs beachtet werden würden.
Wäre dem so, wäre das typische "hello World" mal fix einige tausend Zeilen Code länger -.-
Bei Zen+ funktioniert es seltsamerweise. Da ist man eben davon ausgegangen, dass es bei Zen2 genau so ist.
Heute kommt auch keiner mehr auf die Idee, einen Fix für den FDIV-bug in seine Bootroutine zu implementieren.
Was sagt der Postbote, wenn dein Nachbar dieselbe Hausnummer hat wie du?
Son scheiß, genau.
Lese die Beiträge von Piktrogramm nochmal durch, der hat es auf den Punkt gebracht.
ja, son scheiß, genau. nämlich scheisse programmiert, muss das programm halt abchecken, wenn zwei zufahlszahlen gleich sind. und dann halt +1 rechnen oder was auch immer.
).
