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

[flmr]

Erstmal ist auffällig, dass Destiny2 unter Windows auch ein Problem hatte, dass sich damit löst. Daraus folgere ich, dass die Entropie auch einen guten Moment nach dem Boot schlecht sein kann.

RDRAND hat ueberhaupt nichts mit der Bootzeit zu tun, sondern urandom. urandom hat wiederum nichts mit D2 zu tun. Was willst du eigentlich sagen?

Zweitens liefert RDRAND nach Spezifikation kryptographisch verwertbaren Output, Wikipedia sagt:

Unabhängig von der NSA Diskussion die es da gab, ist es durchaus wahrscheinlich, dass sich manche Software mit Verschlüsselungsbedürfnissen auf das Ding als Quelle verlässt. Es ist ja da, es soll funktionieren, und die Wege von Entwicklern sind unergründlich.

Ich hab keinen Beweis, aber einen Gegenbeweis wird man auch nicht finden können. Solange das so ist, nehme ich eine potenzielle Gefahr wahr.

Jede erstzunehmende krypto-software steht unter freier Lizenz, insofern kannst du durchaus dort nachschauen, ob man sich auf RDRAND verlaesst. Disclaimer: nein.

Das ist sicherlich nur die Spitze des Eisbergs. Ohne Zufallsgenerator kann man so eine CPU ja eigentlich knicken. Bei sowas wird dann schnell klar, dass Intel AMD eben doch noch haushoch überlegen ist.

Extra neuen Account angelegt, damit man mal richtigen Schrott posten kann oder was?

 

[nazgul77]

Testet doch einfach mal welche ältere CPU betroffen ist. Golem hat doch in dem Beitrag einen Test verlinkt(direkt).

Keine Probleme mit AMD A12-9700P direkt nach dem Aufwachen aus dem Standby

nazgul@hp ~ $ gcc test-rdrand.c -o test-rdrand
nazgul@hp ~ $ ./test-rdrand
success: 1 value: ed64f3f834db374a
nazgul@hp ~ $ ./test-rdrand
success: 1 value: 6152cbf9764c455e
....

 

[pseudopseudonym]

Die haben auf dem Teil nicht mal ein Linux getestet?
Oh jee, das Teil kann doch nicht nur zum Spielen gedacht sein!

Ergänzung (14. Juli 2019)

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

Also wenn ich basteln wollte, würde ich auch zum Arbeiten Windows nutzen.
Meine Linux-Systeme machen weniger Arbeit als meine Windows-Systeme.

Ergänzung (14. Juli 2019)

Server verwenden UNIX und nicht Linux

Erzähl mir mehr

 

[Piktogramm]

Die haben auf dem Teil nicht mal ein Linux getestet?
Oh jee, das Teil kann doch nicht nur zum Spielen gedacht sein!
[...]

Die Grüchteküche sagt, Zen2 wurde auf Ubuntu 18.04 getestet. Was nicht verwunderlich ist, schließlich ist der Start der Plattform bisher auf (Windows) Gamer ausgerichtet. Die dürfen Bugs suchen bevor die Produkte von OEMs ausgeliefert werden oder gar Epyc2 spruchreif ist.

Nach all den Jahren Verlusten hat AMD nicht unbegrenzt Ressourcen.

 

[pseudopseudonym]

Die Grüchteküche sagt, Zen2 wurde auf Ubuntu 18.04 getestet. Was nicht verwunderlich ist, schließlich ist der Start der Plattform bisher auf (Windows) Gamer ausgerichtet. Die dürfen Bugs suchen bevor die Produkte von OEMs ausgeliefert werden oder gar Epyc2 spruchreif ist.

Nach all den Jahren Verlusten hat AMD nicht unbegrenzt Ressourcen.

Nja, irgendwie verständlich ist es ja (zumindest bei den Desktop-CPUs), aber das kann man besser machen.
Wie dem auch sei, in n paar Wochen ist das Ding hoffentlich ausreichend "erforscht" für den Heimserverbetrieb. Irgendwann würde ich das Teil gerne in nen VM-Host packen.

 

[Hayda Ministral]

Die Grüchteküche sagt, Zen2 wurde auf Ubuntu 18.04 getestet.
[...]
Nach all den Jahren Verlusten hat AMD nicht unbegrenzt Ressourcen.

Linux bzw. SystemD ist hier aber nur der Bote der die schlechte Nachricht überbringt. Die Nachricht lautet: Es gibt da einen CPU-Befehl der vollkommen kaputt ist. Und egal wie begrenzt die Ressourcen sind, so einen Bug unkommentiert durchrutschen zu lassen ist Zeichen eines tiefsitzenden Problem im Qualitätsanspruch, das schon ziemlich nahe dran kommt an "Och, die FPU verrechnet sich ab und an - aber das ist schon ok lieber User, das braucht Dich nicht zu stören" (Intel, FDIV Bug, afair dank dem Mördereinlauf den die Pappnasen dafür kassiert haben gibt es heute öffentliche Errata-Listen) und " ach ja, übrigens sind alle unsere sogenannten "Sicherheitsfeatures" Schlangenöl, aber das ist schon ok, denn ....ach was, ""ist schon ok"" muss reichen" (Spectre und Co).

Als Positiv sehe ich es das man den Bug per Patch fixen konnte. Dennoch eine saudumme Verhaltensweise von AMD. Mit schneller und gründlicher Information hätte man sich als zuverlässiger Partner der Kunden präsentieren können, stattdessen wird einmal mehr klar gestellt dass auch bei AMD der Kunde im Mittelpunkt und damit vor allem im Wege steht.

 

[Hauro]

Als Positiv sehe ich es das man den Bug per Patch fixen konnte. Dennoch eine saudumme Verhaltensweise von AMD.

Wie dieser hier von Intel, der die CPU zum Absturz bringt - wie konnte Intel nur diesen Bug nicht bemerken:
Skylake, Kaby Lake chips have a crash bug with hyperthreading enabled (6/26/2017, 9:30 PM)

A fix is available for Linux systems; Windows users will have to use firmware updates.

Under certain conditions, systems with Skylake or Kaby Lake processors can crash due to a bug that occurs when hyperthreading is enabled. Intel has fixed the bug in a microcode update, but until and unless you install the update, the recommendation is that hyperthreading be disabled in the system firmware.

Updated my Thinkpad T460 firmware yesterday (surprisingly painful under Linux, as Lenovo in their infinite wisdom only distribute an ISO image, for a machine without an optical drive). Reading the release notes, the first version with the updated microcode was released June 5th.

Und dieser betrifft Windows und Linux.

Weitere Bugs von Intel sind hier #72 gelistet.

Die Micro-Codes von Intel und AMD sind voll mit Korrekturen.

 

[Hayda Ministral]

Ich komme einfach nicht dahinter was Du uns damit sagen willst. Kannst Du das mal bitte erläutern was Intels Fehler mit AMDs Verhalten zu tun hat?

 

[Hauro]

Kannst Du das mal bitte erläutern was Intels Fehler mit AMDs Verhalten zu tun hat?

Das beide Fehler machen, diese in den Tests nicht bemerken und über eine Micro-Code-Korrektur beheben. Auch Intel hat einen Bug erst bemerkt nach dem die CPU längst im Einsatz war.

P.S.
Ist nicht schön, aber in der Softwareentwicklung geht auch so einiges durch.

 

[Hayda Ministral]

Ich lese im verlinkten Artikel gleich zu Beginn "Under certain conditions,[...]".

Das ist keine Entschuldigung, der Fehler hätte vor Release gefunden werden müssen. Es ist aber (meiner Meinung nach) eine ganz andere Hausnummer wenn gleich der ganze Befehl komplett Müll liefert. Genau das tut/tat der neue Ryzen dem Artikel zufolge, er lieferte immer -1. Nicht unter bestimmten Umständen, einfach immer. Korrigiere mich ruhig wenn ich das falsch verstanden habe, denn das ist die Grundlage meiner Kritik.

 

[aldaric]

Ich komme einfach nicht dahinter was Du uns damit sagen willst. Kannst Du das mal bitte erläutern was Intels Fehler mit AMDs Verhalten zu tun hat?

Du wirfst AMD vor, dass man so einen Bug unbedingt bemerken muss. Intel muss das also nicht ?

 

[MaverickM]

Sieben Seiten Diskussion über einen Bug, der bereits gefixt wurde/wird. Ich frage mich, was es da eigentlich wirklich zu diskutieren gibt!?

 

[Hayda Ministral]

Du wirfst AMD vor, dass man so einen Bug unbedingt bemerken muss.

Ja, das tue ich.

Intel muss das also nicht?

Intels Verhalten ist hier nicht mein Thema, der Artikel handelt vom Bug in AMDs neuer CPU. Und zweimal Falsch ergibt in der Welt der Erwachsenen auch nicht einmal Richtig, es ist daher für mich vollkommen irrelevant was Intel macht solange es um AMDs Verhalten/Qualitätsprobleme geht.

 

[Hauro]

Nicht unter bestimmten Umständen, einfach immer. Korrigiere mich ruhig wenn ich das falsch verstanden habe, denn das ist die Grundlage meiner Kritik.

Dann geben Sie jetzt eine Bewertung der Bugs mit entsprechenden Datenmaterial und Studien ab, das jeder beurteilen kann was kritischer ist und wie häufig er auftritt. Dabei ist dann auch die entsprechende Behebung zu berücksichtigten und ob diese zu 100% greifen.

Sonst bleibt jedem die entsprechend CPU nicht zu kaufen.

 

[Ratz_Fatz]

Keine Probleme mit AMD A12-9700P direkt nach dem Aufwachen aus dem Standby

nazgul@hp ~ $ gcc test-rdrand.c -o test-rdrand
nazgul@hp ~ $ ./test-rdrand
success: 1 value: ed64f3f834db374a
nazgul@hp ~ $ ./test-rdrand
success: 1 value: 6152cbf9764c455e
....

Testet doch einfach mal welche ältere CPU betroffen ist. Golem hat doch in dem Beitrag einen Test verlinkt(direkt).

AMD A6-9500 ebenfalls okay. Vielleicht gibt es einen, der das mit einem 2200G, 2400G, 3200G,3400G testet?

 

[Hayda Ministral]

Nun wechselst Du von nicht funktionierendem CPU-Befehl zu Sicherheitslücken. In meinen Augen vergleichst Du Äpfel mit Birnen. Kann man machen, ist aber nicht wirklich sinnvoll. Mir geht es nicht um Bashing sondern um das konkrete Verhalten.

 

[Hauro]

nicht funktionierendem CPU-Befehl

Ist doch bereits behoben. Wie geschrieben stecken in den Micro-Codes viele Fehler-Behebungen, die die meisten gar nicht mitbekommen. Hier muss sich einer vom Fach dazu äußern. Bin aus dem Software-Bereich und was hier zum Teil vorkommt, lassen wir das besser.

P.S.
Wäre der Fehler vorher behoben worden, wäre dieses Thema hier gar nicht aufgekommen, die Lösung wäre aber dieselbe. Der Unterschied wäre aber das es nicht so hoch gespielt würde, da es niemand mitbekommen hätte.

 

[aldaric]

@Hauro

Die Leute brauchen halt was zu meckern. Fehler erkannt, Fehler gemeldet, Fehler wurde beseitigt. Was es da noch dann weiterhin zu diskutieren gibt....

 

[Piktogramm]

Du wirfst AMD vor, dass man so einen Bug unbedingt bemerken muss. Intel muss das also nicht ?

Es sind unterschiedliche Fehlertypen. Normalerweise sollte man erwarten, dass Prozessoren automatisiert getestet werden, wobei jeder Befehl mehrfach ausgeführt wird samt Kontrolle, ob die Ausführung ok war. Bei RDrand hätte da auffallen müssen, dass die Befehle sich nicht an die Spec halten.
Das verstimmt schon etwas, denn dass so ein Fehler zum Release da ist deutet daraufhin, dass da AMD sehr wenig getestet hat.. Wäre das Selbe für alle anderen Hersteller von CPUs

Die zuletzt bekannt gewordenen Intel Bugs waren in der Regel derart komplex, dass sie bei automatisierten Tests kaum auffallen dürften.

Und Fehler gefixt... Hat mal jemand Dokumentiert gesehen, wie sich die CPUs jetzt verhalten? Also liefern die Zufall[1], der bei statistischen Tests hält oder setzen die einfach immer das C-Flag auf "false"?

[1] Vor allem, dass auch nach zig Zustandänderungen der Zufall immer noch taugt.

 

[MaverickM]

Normalerweise sollte man erwarten, dass Prozessoren automatisiert getestet werden, wobei jeder Befehl mehrfach ausgeführt wird samt Kontrolle, ob die Ausführung ok war. Bei RDrand hätte da auffallen müssen, dass die Befehle sich nicht an die Spec halten.
Das verstimmt schon etwas, denn dass so ein Fehler zum Release da ist deutet daraufhin, dass da AMD sehr wenig getestet hat.

Immer vorausgesetzt, der Fehler trat in den synthetischen Tests überhaupt auf. Ist denn sicher, dass der Fehler in Hardware ist, oder nur eine fehlerhafte AGESA/Micro-Code Version!?