News Ryzen 3000: BIOS-Update gegen Probleme mit Linux und Destiny 2

teufelernie

Lt. Commander
Dabei seit
Sep. 2004
Beiträge
1.572

Vollkorn

Banned
Dabei seit
Nov. 2016
Beiträge
1.371
sind hoffentlich nur kinderkrankheiten die bald in vergessenheit geraten
 

mylight

Lt. Junior Grade
Dabei seit
März 2019
Beiträge
330
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
 

crogge

Lieutenant
Dabei seit
Okt. 2004
Beiträge
674
Solange es keine Sicherheitslücken erzeugt kann man beruhigt auf ein Fix warten, glücklicherweise lässt sich zumindest das Linux Problem beheben.
 

ghecko

Rear Admiral
Dabei seit
Juli 2008
Beiträge
6.089

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.967
Okay... aber warum braucht Destiny 2 beim Start eine Zufallszahl?

(Und wofür brauchen diverse Linux-Distros eine?)
Linux / systemd:
Erklärung u.a. von hier: https://github.com/systemd/systemd/issues/11810

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
 

aldaric

Vice Admiral
Dabei seit
Juli 2010
Beiträge
6.320
Breichtigt mich, aber das hat Intel bei Release doch besser drauf
@Transistor 22

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.
 

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.967
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 :D).
Naja und systemd nutzt wenn es um Sicherheit geht auch nicht RDrand sondern fragt brav /dev/urand
Ergänzung ()

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.
 
Zuletzt bearbeitet:

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.510
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.
Typisch Poettering, aber lassen wir das.

Derr Anwortkommentar auf diesen erklärt dann einiges: https://github.com/systemd/systemd/issues/11810#issuecomment-509554660

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.
 

Hibbelharry

Ensign
Dabei seit
Juni 2004
Beiträge
228
Ich sag es mal so wie es ist: Destiny2 spiele ich nicht. Linux nutzte ich auch nicht am PC. Also mich jucken die Bugs nicht.
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.

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.

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.
Die interesanten Distros für Unternehmen wie RHEL oder Debian oder Ubuntu LTS laufen.

Ich habe das Gefühle das AMD Gamer und andere Ryzen 3000 Nutzer als Betatester für Zen 2 nützt.
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.
 

Stunrise

Captain
Dabei seit
Feb. 2008
Beiträge
3.175
Okay... aber warum braucht Destiny 2 beim Start eine Zufallszahl?

(Und wofür brauchen diverse Linux-Distros eine?)
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.
 

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.967
[...]
Anstatt also einen Workaround zu benutzen, gibt es folgende Begründung:
Typisch Poettering, aber lassen wir das.
[...]
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.
 
Zuletzt bearbeitet:

yummycandy

Captain
Dabei seit
März 2005
Beiträge
3.510

Mickey Cohen

Lt. Commander
Dabei seit
Mai 2015
Beiträge
1.447
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.
 

ghecko

Rear Admiral
Dabei seit
Juli 2008
Beiträge
6.089
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.
 
Zuletzt bearbeitet:

Snudl

Ensign
Dabei seit
Apr. 2016
Beiträge
146

Piktogramm

Rear Admiral
Dabei seit
Okt. 2008
Beiträge
5.967
@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 -.-
 

Mickey Cohen

Lt. Commander
Dabei seit
Mai 2015
Beiträge
1.447
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.
 
Top