News Beta-Chipsatztreiber: Destiny 2 startet erstmals auf AMD Ryzen 3000

[DocWindows]

Im AMD Architecture Programmer's Manual steht dann auch noch:

If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.

Und es ist ja nicht so, dass keine Alternative bestünde:

AMD: AMD RNG Library
OpenCL: clRNG

Wenn du alles lesen würdest, hättest du erkannt dass die Definition ob ein Zufallswert gültig oder ungültig ist, das CF Register bestimmt, also die CPU. Und dieses Register wird falsch gesetzt.

Hardware modifies the CF flag to indicate whether the value returned in the destination register is valid. If CF = 1, the value is valid. If CF = 0, the value is invalid. Software must test the state of the CF flag prior to using the value returned in the destination register to determine if the value is valid. If the returned value is invalid, software must execute the instruction again. Software should implement a retry limit to ensure forward progress of code.

Die CPU entscheidet ob der Zufallswert gültig ist oder nicht. Nicht die Software die die Funktion nutzt.
Und wenn immer "Kann ich nicht" zurückgegeben wird, solltest du ein rety limit beachten um einen Lock zu vermeiden. AMD gibt aber immer "Kann ich" zurück.

Zu AMDs RNG library:

The AMD Secure Random Number Generator (RNG) is a library that provides APIs to access the cryptographically secure random numbers generated by AMD’s hardware-based random number generator implementation. These are high quality robust random numbers designed to be suitable for cryptographic applications. The library makes use of RDRAND and RDSEED x86 instructions exposed by the AMD hardware

Tolle Alternative.

Stimmt schon. Der Bug im Zufallsgenerator ist IMHO aber eigentlich nicht sooo tragisch, denn er besteht wohl "nur" darin, dass die CPU als Wert -1 zurückliefert und diesen Wert dennoch als gültig deklariert (also das Fehlerbit nicht setzt).

Aber spitzfindigerweise ist auch unendlich Mal -1 letztlich eine Zufallsfolge. Programme, die "echten" Zufall brauchen, dürfen sich nicht nur auf eine Quelle verlassen. Vermutlich landet hier irgendwas in einer Endlosschleife, weil es bei einem als ungültig interpretierten Wert (-1) sofort einen neuen Versuch startet (und wieder -1 zurückbekommt).

Auch für dich: Die CPU meldet jedes Mal dass der Zufallswert gültig ist. Über Gültigkeit entscheidet die CPU, nicht das Programm. Und Programme die echten Zufall brauchen, dürfen sich sehr wohl auf diese Funktion in der CPU verlassen, denn AMD sichert die Zufälligkeit explizit zu.

The AMD Secure Random Number Generator (RNG) is a library that provides APIs to access the cryptographically secure random numbers generated by AMD’s hardware-based random number generator implementation. These are high quality robust random numbers designed to be suitable for cryptographic applications.

 

[derSafran]

Also da kommt mir irgendwie der P68 Bug in Erinnerung. Da hat Intel über 1 Mrd $ rausgehauen um MBs zurückzurufen, und der Vertrieb um fast 3 Monate herausgezögert, um einen Fehler zu beheben der ähnlich belanglos war. Und alle schrien dann: "Intel - was für ein Drecksladen".

Nur das sich dabei (so wie bei mir, der nicht getauscht hat, weil er zocken wollte) nach und nach USB-Ports, Laufwerke und am Ende das ganze Board verabschiedet hat. In diesem Fall bittet ist es nur ein Ärgernis.
Egal wie man es nimmt, es trifft die Early-Adopter.
Da ich sowohl bei Phenom, als auch bei Sandy Bridge reingefallen bin, warte ich vor einem Wechsel immer zwei Monate ab. Im September lege ich mir dann auch endlich einen Ryzen zu :]

 

[VelleX]

Für das asrock B450M Steel Legend und x570 taichi gibt es mittlerweile ein neues BIOS für destiny 2

Improve Destiny2 gaming experience with Matisse CPU.

 

[ZeroStrat]

Die CPU meldet jedes Mal dass der Zufallswert gültig ist. Über Gültigkeit entscheidet die CPU, nicht das Programm.

Warum sollte das Programm nicht auch über die Gültigkeit entscheiden?

 

[Nozuka]

Wäre hier ja schon lange nicht mehr so viel los, wenn alles auf anhieb funktionieren würde...

 

[corvus]

Für das asrock B450M Steel Legend gibt es mittlerweile ein neues BIOS für destiny 2

Die Beschreibung finde ich witzig. Hab mich ja selber an Destiny 2 versucht, aber war halt irgendwie nur Grinding. Ob der Programmstart daher zu einer besseren "experience" führt ist eher Geschmackssache. Aber gut, dass die Sache nun über ein BIOS Update behoben werden kann. Ob damit auch das Linux-Startproblem weg ist?

 

[Cl4whammer!]

Ob damit auch das Linux-Startproblem weg ist?

KA was das Bios macht, ob die schon das neue Agesa von AMD haben? O.o Was selbstgebautes?
Für beides ist auf jeden Fall der selbe "Fehler" verantwortlich. Der Chipsatztreiber ist nur eine zwischenlösung (Auf angeblich kosten von SVM das man dann deaktivieren muss) und die funktioniert nur mit Windows. Da müsste noch ein Bios kommen was beides auf einen schlag behebt.

 

[DocWindows]

Warum sollte das Programm nicht auch über die Gültigkeit entscheiden?

Weil das Programm nicht beurteilen kann ob die Zahl eine Zufallszahl ist, da die Ermittlung "in Hardware" stattfand und somit außerhalb des Programms. Die Hardware bestätigt deshalb selbst per CF Flag dass die Ermittlung der Zufallszahl funktioniert hat. Das ist dann auch gleichzeitig die Garantie, dass die in der Doku angesprochene Qualität der Zufallszahl gegeben ist.

Vor dem Hintergrund der Kryptografie wäre es auch denkbar dass der Security Prozessor innerhalb der CPU die Generierung überwacht oder dass die Generierung direkt in diesem Prozessor stattfindet.

All das kann das Programm nicht einsehen, also fehlt jegliche Grundlage für das Programm den Zufallswert zu beurteilen. Aber auch Abseits der Kryptografie fehlt dem Programm jegliche Grundlage für eine Beurteilung.

 

[owned139]

Weil die Entwickler einmal mehr unfähig sind...

Warum sollte der Entwickler Schuld sein, wenn ein Feature der CPU nicht so funktioniert, wie von AMD angegeben? Ergibt keinen Sinn, aber wieso auch AMD blamen? Die anderen sind ja immer Schuld.

Dieser AMD Circlejerk nervt extrem.

 

[Piktogramm]

Warum sollte das Programm nicht auch über die Gültigkeit entscheiden?

Wenn CPUs bei jedem X86 Befehl erst dessen richtige Ausführung prüfen müssten hast du schnell mal Faktor 100-100.000 bei der Codekomplexität. Bei um ähnliche Faktoren reduzierter Performance bei gleichzeitig deutlich gesteigertem Speicherbedarf. Eine super Möglichkeit um uns auf Intel Pentium Performance Level zurückzusetzen.

Super Idee...

Ergänzung (30. Juli 2019)

Ob damit auch das Linux-Startproblem weg ist?

Das Problem unter Linux, genauer SystemD ist weg weil in SystemD eine Sonderbehandlung eingeführt wurde. Das AGESA Update was das Problem fixen sollte hat zu Problemen bei PCIe4 geführt und wird deswegen bisher nicht verteilt.

Der SystemD fix ist im Übrigen maximal hässlich:
Wenn RDRAND -1 zurückgibt, dann nutze alternative Zufallsquelle

Ich hoffe, dass das ein temporärer Fix bleibt -.-

 

[Ned Flanders]

Warum sollte man das kaputte Rating des einen Tools mit Hilfe des kaputten Ratings eines anderen Tools aufzeigen? Passmark ist genauso Schrott.

Wenn CPUs bei jedem X86 Befehl erst dessen richtige Ausführung prüfen müssten hast du schnell mal Faktor 100-100.000 bei der Codekomplexität.

Aber Destiny2 prüft/beurteilt ja offensichtlich, sonst wäre es ja mit -1 zufrieden und würde booten.

Oder was ist Eure Erklärung.

Für das asrock B450M Steel Legend und x570 taichi gibt es mittlerweile ein neues BIOS für destiny 2

Das ist interessant. Da es ein Beta BIOS ist, bedeutet das wohl, dass der gefixte AGESA Code bei den Board Partnern ist und kurz vor der Auslieferung steht.

 

[Piktogramm]

All das kann das Programm nicht einsehen, also fehlt jegliche Grundlage für das Programm den Zufallswert zu beurteilen. Aber auch Abseits der Kryptografie fehlt dem Programm jegliche Grundlage für eine Beurteilung.

Wieso denn die Software könnte einige (tausende) Zufallswerte erzeugen und statistische Testverfahren drüber laufen lassen. Dann für was hat man denn seine 12 Kerne im Desktop?

Ergänzung (30. Juli 2019)

Aber Destiny2 prüft/beurteilt ja offensichtlich, sonst wäre es ja mit -1 zufrieden und würde booten.

Die Fehlerbeschreibung von Destiny klingt eher so, als ob sich das Programm in einer Endlossschleife verheddert. Was darauf hinweißt, dass da keine Tests (außer evtl auf das CFlag) stattfinden. Damit wäre das dann das selbe Fehlerbild wie bei SystemD.

 

[Gast0ne]

Wenn du alles lesen würdest, hättest du erkannt dass die Definition ob ein Zufallswert gültig oder ungültig ist, das CF Register bestimmt, also die CPU. Und dieses Register wird falsch gesetzt.

Wenn Du richtig zitieren könntest, wüsstest Du, dass der Beitrag von mir und nicht NedFlanders gekommen ist.

Auch für dich: Die CPU meldet jedes Mal dass der Zufallswert gültig ist. Über Gültigkeit entscheidet die CPU, nicht das Programm. Und Programme die echten Zufall brauchen, dürfen sich sehr wohl auf diese Funktion in der CPU verlassen, denn AMD sichert die Zufälligkeit explizit zu.

Der Aufrufer erhält eine Zahl. Den Wertebereich dieser Zahl muss der Aufrufer schon selbst prüfen, denn nur er weiß, wofür er diese Zahl letztlich einsetzen will. Die CPU sichert im Zufälligkeit zu, nicht mehr und nicht weniger. Und wie bereits festgestellt ist auch eine Folge gleicher Zahlen zufällig. Um die Zufälligkeit zu validieren - aber darum geht es hier nicht - müsste der Aufrufer sehr viele Zufallszahlen anfordern und darüber eine Statistik machen.

Zu AMDs RNG library:
Tolle Alternative.

Wenn Du den Source Code dieser Bibliothek eingesehen hättest (aber auch Doktoren machen heutzutage leider nur sehr oberflächliche Diagnosen, nicht wahr), wüsstest Du, dass die Library sehr wohl eine Alternative gewesen wäre, denn die Implementierung ist korrekt und begrenzt die Anzahl wiederholter Aufrufe über einen Retry-Counter:

  if (ret == SECRNG_SUPPORTED) 
  {
        ret = SECRNG_FAILURE;
        unsigned long long *lrng_val = (unsigned long long *)rng_val;
        //Invoke the rdrand intrinsic function 
        if (_rdrand64_step(lrng_val))
                ret = SECRNG_SUCCESS;
        else if (retry_count > 0)
        {
                //Check number of retries does not exceed the max limit
                retry_count = (retry_count > MAX_RETRY_COUNT)? MAX_RETRY_COUNT : retry_count;
                int i;
                for (i = 0; i < retry_count; i++)
                {
                        if (_rdrand64_step(lrng_val))
                        {
                                ret = SECRNG_SUCCESS;
                                break;
                        }
                }
        }
  }
  return ret;

Die Destiny-Macher hätten das nur so abschreiben brauchen und das Problem wäre keines geworden.

 

[0xffffffff]

Ich schlichte das Streitgespräch mal mit einer simplen Feststellung:

• Systemd nutzt einen direkten Aufruf von "rdrand" anstelle der entsprechenden Kernelfunktionen welche eben jenes wrapped bzw. mit zusätzlichen (PSeudo-)Zufalls-Quellen anreichert -> Fragwürdige Entscheidung seitens Systemd
• Systemd ignoriert das "success"-Flag der rdrand-Instruktion wenn das Ergebnis nach Meinung von Systemd nicht gut aussieht und fragt infolgedessen auf ewig weiter mittels rdrand nach Zufallszahlen -> Endlosschleife, definitiv ein Fehler von Systemd, entweder schenken sie dem Success-Flag glauben oder bauen entsprechend ein Limit ein, so wie es auch das Manual empfiehlt
• Der Prozessor offerriert scheinbar valide Zufallszahlen, liefert aber reproduzierbar die ganze Zeit nur "-1" als Wert zurück -> Sehr fragwürdig, empfinde ich definitiv als Fehler da kein statistisch gutes Rauschen

Beide haben etwas verkackt, dass aber Linux nicht mehr ordentlich booten konnte kreide ich persönlich ausschließlich dem "Not Invented Here"-Syndrom bzw. einem Bug von Systemd an. Da können die so viel mit dem Finger auf andere zeigen wie sie wollen.

 

[nille02]

@Gast0ne, das hätte sie nicht weiter gebracht, denn die CPU sagt ja das alles Ok ist. Um einen Fehler zu vermeiden hätten sie die Ergebnisse vergleichen müssen.

 

[owned139]

Die Destiny-Macher hätten das nur so abschreiben brauchen und das Problem wäre keines geworden.

AMD hätte nur einen ordentlichen Zufallszahlengenerator entwickeln müssen und das Problem wäre keines geworden. Merkste?
Die Ursache ist die CPU und nicht der Code. Alles andere ist nur drumherumgefrickel. Klar kann man mit Software gewisse Hardwarefehler fixen/umgehen, aber dann brauch ich auch die Hardware nicht mehr?!

 

[Gast0ne]

All das kann das Programm nicht einsehen, also fehlt jegliche Grundlage für das Programm den Zufallswert zu beurteilen. Aber auch Abseits der Kryptografie fehlt dem Programm jegliche Grundlage für eine Beurteilung.

AMDs RDRAND Implementierung ist im Crypto-Coprozessor von Ryzen und Epyc enthalten und verwendet Oszillatoren als Entropiequelle (siehe https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf). Aber die Zufälligkeit der Zahlen ist hier nicht das Problem.

Warum sollte der Entwickler Schuld sein, wenn ein Feature der CPU nicht so funktioniert, wie von AMD angegeben? Ergibt keinen Sinn, aber wieso auch AMD blamen? Die anderen sind ja immer Schuld.

Am NIH-Syndrom der Destiny-Macher hat AMD keine Schuld. Der Fehler war bereits lange bekannt - u.A. bei systemd und dem Linux-Kernel waren Workarounds bereits seit Monaten eingebaut. Bibliotheken zur Generierung von Zufall stehen seit Jahren zur Verfügung.

Niemand entschuldigt AMD, aber zu diesem Problem hier gehören Zwei.

Ergänzung (30. Juli 2019)

AMD hätte nur einen ordentlichen Zufallszahlengenerator entwickeln müssen und das Problem wäre keines geworden. Merkste?

Destiny ist das einzige Spiel das absemmelt. Merkste?

 

[nille02]

Systemd nutzt einen direkten Aufruf von "rdrand" anstelle der entsprechenden Kernelfunktionen welche eben jenes wrapped bzw. mit zusätzlichen (PSeudo-)Zufalls-Quellen anreichert -> Fragwürdige Entscheidung seitens Systemd

Sie wird aber begründet, zu dem zeitpunkt hat der kernel noch nicht genug Entropie und systemd müsste warten bis genug vorhanden ist. Man braucht aber keine Kryptografisch sichere Zahlen, sondern einfach eine Zufallszahl reicht ihnen.

Systemd ignoriert das "success"-Flag der rdrand-Instruktion wenn das Ergebnis nach Meinung von Systemd nicht gut aussieht und fragt infolgedessen auf ewig weiter mittels rdrand nach Zufallszahlen -> Endlosschleife, definitiv ein Fehler von Systemd, entweder schenken sie dem Success-Flag glauben oder bauen entsprechend ein Limit ein, so wie es auch das Manual empfiehlt

Das haben sie nicht ignoriert. Sie kamen in eine Endlosschleife weil sie keine gültigen uuids erstellen konnten und nicht weil die Zufallszahl nicht "gut" war. Da das Starten des Systems von den Zufallszahlen abhängig gemacht wurde, hätte man die Zahlen aber auch betrachten sollen. Dabei hätte man schnell erkannt das der Generator nicht korrekt funktioniert und den langsameren Fallback nutzen können. Wobei ich es schon schlecht finde einfach nur Zufallszahlen für UUIDs zu nutzen, da gibt es andere Verfahren die zu erstellen die sinnvoller wären.

Der Prozessor offerriert scheinbar valide Zufallszahlen, liefert aber reproduzierbar die ganze Zeit nur "-1" als Wert zurück -> Sehr fragwürdig, empfinde ich definitiv als Fehler da kein statistisch gutes Rauschen

Beide haben etwas verkackt, dass aber Linux nicht mehr ordentlich booten konnte kreide ich persönlich dem "Not Invented Here"-Syndrom von Systemd an.

Wie du schon sagst, der Fehler bei AMD ist unstrittig. Und systemd hat Technisch erst mal alles richtig gemacht. CPU meldette eine korrekte Zahl und wie hier auch schon eingeworfen wurde, wenn man der CPU nicht mehr vertraut ihre Instruktionen korrekt auszuführen, hat man ein Problem. Wenn ein Spiel abstürzt, kann ich das nachvollziehen und ein Auge zu drücken, aber wenn eine Schlüsselkomponente abstürzt, ist das nicht mehr witzig. Besonders da die Entwickler von systemd über das Problem schon seit Monaten (Ich meine der Bug war erstmals aus dem Mai) in Kenntnis gesetzt wurden auf Seiten des Kernel bereits seit 2014.
Man hätte einen Workaround einfach einbauen können und alles wäre gut gewesen. Aber nein, sie Meckern lieber, sie seien nicht zuständig und zeigen auf AMD. Wie gesagt, bei einer einfachen Anwendung könnte ich das verschmerzen, aber bei systemd booten die Systeme nicht mehr.

 

[Jesterfox]

Systemd ignoriert das "success"-Flag der rdrand-Instruktion wenn das Ergebnis nach Meinung von Systemd nicht gut aussieht und fragt infolgedessen auf ewig weiter mittels rdrand nach Zufallszahlen -> Endlosschleife, definitiv ein Fehler von Systemd, entweder schenken sie dem Success-Flag glauben oder bauen entsprechend ein Limit ein, so wie es auch das Manual empfiehlt

Das Problem ist hier das systemd die Zufallszahlen für etwas benutzt das sie an sich nicht leisten können: zur Generierung von unique IDs. Deswegen müssen sie eine weitere Zufalszahl erzeugen wenn diese sich von der vorherigen nicht unterscheidet und bei einem Zufallsgenerator der immer nur -1 liefert wird das eben blöd ;-)

 

[Ned Flanders]

Niemand entschuldigt AMD, aber zu diesem Problem hier gehören Zwei.

This! Alles andere ist eine wirklich schwer zu haltende Darstellung. Das ergibt sich ja schon aus der Häufigkeit der Manifestation eines Problems.