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

[Player(1)]

@Transistor 22 @Silveran
Danke euch beiden fuer eure ueberaus wertvollen Beitraege.

So zu rechnen ergibt wenig Sinn. ComputerBase läuft z.B. mit Linux, d.h. jeder, der das hier liest, nutzt indirekt Linux. Würde man in den Server eine solche CPU einbauen, würde das System evtl. nicht booten und CB wäre offline.

Normalerweise wechselt man nicht mal eben, bei einem laufendem Produktivsystem, die CPU bzw die Konfiguration oder setzt blind irgendein ungetestetes System auf (ka wie das ueberhaupt gehen sollte) und stellt das einfach in eine Serverfarm.
Man testet halt dann doch schon seine Projekte, bevor die gelauncht werden.

Also keine Angst, da geht nichts mal eben offline.

AMD hat da halt wohl bisschen geschludert. Ist zwar irgendwie doof, aber auch kein Beinbruch. Sind halt Kinderkrankheiten.

 

[Solavidos]

Stimmt, bei Intel kommt das teils erst Jahre später ans Licht, das ist viel besser.
AMD hingegen überlässt nichts dem Zufall.
Pun intended.

Der Beitrag ist unterbewertet! Wirklich gut mit dem Spruch "AMD überlässt nichts dem Zufall" in diesem Zusammenhang

 

[yummycandy]

Das mit hw Fehler steht ja noch aus, wie im Text erwähnt gibt sich AMD hierzu zugeknöpft...

Ich meinte mit solchen Fehlern, daß die nicht per Microcode gefixed werden können. Ob nun in Silizium oder MC ist eigentlich egal, der Fehler existiert nunmal.

 

[abcddcba]

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.

Oh, wow ... sagte der tolle Softwareentwickler im CB Forum ... wenn man das schon immer liest "scheisse programmiert", und dann der Vorschlag, "halt +1 rechnen" ... von IT Security ergo null Ahnung, stimmt's? Lass es einfach oder mach es besser und mach nen PR fuer den Linux Kernel auf, der das ganze loest.

• der Fehler liegt hier in der Hardware, Ende - der Fehler wird von AMD zeitnah gefixt, Ende
• dass beim Release zur Zeit nicht alles optimal verlaeuft, ist halt so.
• dass viele User mit aelteren Boards aktuell (noch) Probleme haben mit dem BIOS, ist traurig, aber da nehmen sich AMD und Intel wohl nix, zumal die Boardhersteller hier teilweise auch eher ein Armutszeugnis abliefern. Aber hey, die Leute kaufen es doch trozdem immer, egal von welchem Hersteller.
  • wenn man sieht dass Informationen selbst zu X570 Boards wie bei Asus erst nach und nach Online gestellt werden, teilweise auch nicht konsistent sind, sagt doch alles
  • in dem Thread hier hat es der User mal historisch aufbereitet, fand ich ganz "lustig" oder eher erschreckend: https://www.computerbase.de/forum/threads/asus-ws-x570-ace-vs-ecc-ram.1881411/#post-22867039

Also Leute, alles wie immer. Early Adopter muessen halt damit leben, dass es am Anfang Probleme gibt oder manchmal auch gar nix geht. Ist jetzt auch nicht so als wenn das nicht vorher bekannt waere, hat die Vergangenheit ja gezeigt.

Immerhin gibt es Alternativen bei CPUs und GPUs, gibt schlimmeres.

 

[DerHalbmann]

Schade, dass man nicht Free to play und Suchtförderung nicht kategorisch ausschließen kann auf Hardwareebene

 

[flmr]

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.

Das ist zwar grundsaetzlich alles richtig, aber der Kontext ist falsch.

Nicht Linux ist betroffen, sondern systemd (Ueberschrift ist falsch). Der Kernel (Linux) erzeugt Zufallszahlen auf diese Weise (RDRAND ist nur ein zusaetzlicher Faktor von vielen) und stellt sie u.a. fuer die genannten Anwendungen bereit.

Ganz zu Beginn ist aber keine (hinreichende) Entropie vorhanden, man wuerde also darauf warten muessen und damit den Bootvorgang verlangsamen. Da man hier keine Zufallzahlen braucht, die gut genug fuer krypto sind, sondern nur hinreichend gute, um brauchbare UUIDs zu generieren. Deshalb hat man die Optimierung eingebaut, dass RDRAND benutzt wird, wenn die CPU es bereitstellt.

Das ja nicht nur unmittelbar beim Booten, sondern mit Pech auch ne Weile danachm und nicht nur in Linux. Wenn der Zufallszahlengenerator nicht funktioniert, versagen erstmal alle möglichen Sicherheitsmechanismen bzw. erzeugen erratbare Schlüssel, das ist das eigentlich üble gewesen. Du hast ne Haustür mit Schlüssel, aber jeder Schlüsselrohling passt.

Unsinn. Recherchiere mal richtig. Der Bug ist nicht sicherheitsrelevant, weil (aus guten Gruenden) eh noch nie jemand darauf vertraut hat, dass RDRAND hinreichend guten Zufall liefert. RDRAND macht eine Zufallszahl in Linux hoechstens besser, im schlimmsten Fall bleibt sie einfach nur so "gut" wie sie ist, aber niemals schlechter.

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.

Auch du solltest nochmal recherchieren, bevor du auf den systemd-bashzug aufspringst.

Systemd würde also erstmal einige Sekunden (oder länger, auf embedded-Hardware) auf eine Zufallszahl warten und könnte dann erst beginnen zu Booten. Das verlangsamt den Bootvorgang, bringt keinen Sicherheitsgewinn und führt zu Spam im Kernel Log.

Grundsaetzlich ist es richtig was du sagst, Embedded-Hardware hat allerdings oft ueberhaupt kein RDRAND.

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.

Rede nicht so einen Stuss. Du hast offenbar ueberhaupt keine Ahnung von PRNGs.

 

[Kalsarikännit]

nämlich scheisse programmiert, muss das programm halt abchecken...und dann halt +1 rechnen oder was auch immer.

„scheiße programmiert“ und „dann halt einfach xyz rechnen“ sind meine absoluten Lieblingsstichworte im Geschäftsumfeld. Kommen in der Regel von den Admins 😄

Alles in allem bin ich dann doch etwas froh dem ersten Hype widerstanden und nicht sofort den 3700X in die Kiste gerammelt zu haben. Scheint noch etwas reifen zu müssen. Vielleicht war der Termin von AMD „scheiße ausgewählt“ und sie hätten „halt einfach +1 gerechnet“ und das Ding am 8.8. veröffentlicht...wobei das ja immer noch nicht heißt dass die ganzen nun auftretenden Bugs dann schon vorher aufgefallen werden. Die meisten Fehler entdeckst halt doch beim Public Betatest

 

[Benji18]

Meine Meinung ist: Dumm von den Entwicklern den Entschluss zu fassen sich auf etwas verlassen zu wollen, was bisher unzuverlässig war und gerade mal funktioniert. Prinzipien hin oder her. Dumm von AMD sich darauf zu verlassen, dass es wie bisher weiterläuft und sowas nicht geprüft oder gefixt werden muss (wobei der Releasezeitpunkt langsam Zeitkritisch wurde). Aber hier handelt es sich immer noch um Desktop und nicht um ausfallsichere Wasweißichsysteme.

kommt drauf an mit welcher Distri version Sie gestestet haben z.b. ubuntu 18.04 läuft einwandfrei mit systemd ab ubuntu 19 booter der rechner dann nichtmehr sprich die entwickler haben auch dinge verändert.

 

[KingLz]

Wie mein alter EDA Prof meinte:
Man kann nur Fehler finden und nicht zeigen, dass Hardware fehlerfrei ist!

Da kann man nur froh sein, dass über Systemd dieser Bug gefunden wurde. Bei Destiny hieß es nur "das läuft nicht" und keiner wusste warum.

Das der Zufallszahlengenerator keine Zufallszahlen liefert sehe ich übrigens auf der gleichen Ebene wie 1+1 != 2. Als Softwareentwickler erwartet man, dass die Hardware funktioniert wie sie soll. Workarounds baut man erst, wenn die Hardware bekannte Fehler hat.

 

[Nozuka]

Der Bug wird behoben sein, bevor die meisten überhaupt ihre CPU bekommen... von daher...

Aber schon seltsam, dass mit so grossen Linux Distros offenbar nicht getestet wurde.

 

[lokon]

systemd würde also erstmal einige Sekunden (oder länger, auf embedded-Hardware)

Systemd auf embedded devices ist "spannend" - nicht nur wegen des Umfangs den es inzwischen hat (und der Platzbeschränkung dort - siehe die Diskussion um AM4 Biosgröße), gerade weil afaik die Ursprüngliche Entwicklungsrichtung aus dem x86 Desktop auch die Prämisse schneller Booten durch Parallelisierung hatte.

systemd provides aggressive parallelization capabilities

Quelle

Die agressive Parallelisierung bringt einerseits Performancegewinne wie kürzere Bootzeiten, aber dabei werden eben auch Probleme entdeckt oder entstehen erst und müssen beseitigt werden - zB Lockingmechanismen, Kohärenzprotokolle und andere Probleme bei Mehrprozessorsystemen in Hard- und Software.
Bei anderen Bootmanagern / Plattformen braucht die Hardwareinitialisierung länger (da serieller Ablauf) und damit kann eben der RNG des Kernels aufgerufen werden.

Die Bootzeit ist heute eigentlich kein großes Argument für Systemd, denn es gibt diverse Projekte die zB auch den Linux Sourcecode zu booten tccboot (2004) - iirc gibt es von solch einem Projekt auch einen Vortrag, der das Live zeigt, bei Youtube oder media.ccc.de finde ich leider nichts.

Interessant das AMD bei internen Tests oder den Engineering Samples den Fehler nicht gefunden hat, denn er scheint beim einfachen Verwenden des CPU Befehls aufzutreten. Man könnte erwarten, dass jeder CPU Befehl mal ausprobiert wird -- die Laufzeit ist deutlich geringer als ein möglicher Prime95 , Furmark oder andere Burn-In Tests zur Stabilität.
Hoffentlich gibt es auf den Spezialkonferenzen der CPU-Entwickler wie Hot Chips einen Vortrag oder in einem Journal einen Beitrag zu den Hintergründen/Erfahrungen. Zum Pentium FDIV bug finden sich bei google scholar einige Publikationen.

 

[-AKI-]

Wie viele nutzen Linux? 3,5%!

Schon mal überlegt wie viele Server weltweit auf Unix / Linux Kernel laufen?

 

[drago-museweni]

Am 12.07 alle.... mimimi, aber das Teil hat einen Bug

Ersetze "Alle" durch ein "kleiner Teil" dann stimmt es vielleicht, beides dürfte für die Mehrheit an Nutzer unbedeutend sein...

@-AKI- es sind aber Aktuell keine Server CPUs, die kommen ja erst später, und da wird das dann vorher schon gefixt sein..

 

[Hibbelharry]

Unsinn. Recherchiere mal richtig. Der Bug ist nicht sicherheitsrelevant, weil (aus guten Gruenden) eh noch nie jemand darauf vertraut hat, dass RDRAND hinreichend guten Zufall liefert. RDRAND macht eine Zufallszahl in Linux hoechstens besser, im schlimmsten Fall bleibt sie einfach nur so "gut" wie sie ist, aber niemals schlechter.

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. Zweitens liefert RDRAND nach Spezifikation kryptographisch verwertbaren Output, Wikipedia sagt:

RDRAND (previously known as Bull Mountain[1]) is an instruction for returning random numbers from an Intel on-chip hardware random number generator which has been seeded by an on-chip entropy source.[2] RDRAND is available in Ivy Bridge processors[a] and is part of the Intel 64 and IA-32 instruction set architectures. AMD added support for the instruction in June 2015.[4]

The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A,[5] FIPS 140-2, and ANSI X9.82.[2]

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.

 

[RaptorTP]

Dann hab ich wenigstens eine Ausrede warum ich das Game nicht zuende spiele .... xD

 

[Hibbelharry]

Wie viele nutzen Linux? 3,5%!

Schon mal überlegt wie viele Server weltweit auf Unix / Linux Kernel laufen?

96,5% der Top 1 Million Websites werden aktuell laut Alexa von Linuxsystemen ausgeliefert, bei den Top 10 Millionen kenne ich als letzte Zahl 75% Linux Anteil.

Die Amazon Cloud (EC2) soll aktuell zu 92% unter Linux laufen. Amazon hat etwa 50% Anteil des Cloudserver Markts. Selbst in Azure sollen die Anteile Linux Installationen beträchtlich sein, mehr als 50% nach Angaben von MS.

Bei den Supercomputern laufen 498 von 500 unter Linux. Windows spielt keine Rolle.

Android und Chromebooks sind etwas diffizil, die kann man aber auch noch zu den Linuxoiden rechnen.

Settopboxen, Kühlschränke, Autoradios, der ganze Embedded Bereich: Linuxlasting.

Am Ende ist das so: Alles was nicht Semischmalspurdesktop auf der Welt ist, läuft auf Linux. Den exakten Marktanteil über alle Gattungen von Maschinen herauszufinden ist schwer, aber Linux dürfte viel grösser sein als die MS Systeme, da wird kaum jemand widersprechen.

 

[acc]

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.

hätten sie, das grundsätzliche problem besteht dann immer noch mit auswirkungen auf die gesamte krypographie. ist also nicht besonders schlau, amd dafür ins schutz zu nehmen.

 

[BorstiNumberOne]

Nur gut, dass sich einer meiner besten Freunde seinen neuen Rechner noch nicht geholt hat. Nach dem Rohrkrepierer Anthem und einen schönen, aber nun reizverflogenen Ausflug in The Division 2, sind er und unser Clan wieder nur in Destiny 2 unterwegs. Und er meinte letztens noch:
„Eigentlich will ich keinen AMD ... mit deren Grakas hatte ich immer Probleme ... und meh ...“.
Und ich dann:
„Nein, die Zeiten sind vorbei, die Ryzen 3000 werden absolut gleichwertig bzw. mit der Kernanzahl noch mehr Auswahl zu besseren Preisen bieten...“. Jetzt hätte er mich glaube ich gehasst.
Nein Spaß beiseite. Ist ein unschöner Bug, der zum Glück nur eine eingeschränkte Usergruppe betrifft und dieser sollte dann ja gefixt sein.

Was mich viel eher gerade bei Frage Intel oder AMD stört ist, dass man bei Ryzen 3000 nun ein runderes CPU Portfolio hat, aber die Mainboards mit dem X570 Chipsatz diesen nervigen Quirl mitbringen und dazu mit Ihren Preisen, welchen den Gesamtpreis aus CPU und Motherboard gegenüber Intel relativieren. Gut, ich hätte dann hier wahrscheinlich lieber zu einem X470 Board gegriffen, aber da sind die BIOSe nicht final bzw. kommt ja jetzt noch die Größe des 16MB BIOS Bausteins als Engpass hinzu, wo die Hersteller nun mit der Lite Version eine zurechtgefrickelte Lösung anbieten, welche dann ja noch doppelt gepflegt werden muss. Da sind die Boards bei Intel gefühlt runder, dafür die CPUs an der physikalischen Kotzgrenze und das Portfolio arg beschränkt (nein, ein i5 ist außerhalb der Officenutzung keine Alternative mehr). Vom Meltdown Spectre Desaster mal ganz zu schweigen. Meine Tendenz / Empfehlung wäre noch den Sommer zu überbrücken und dann zu kaufen. Dann haben sich die Preise der X570 Boards vielleicht etwas eingependelt oder die X470 ein reiferes BIOS.

 

[Hauro]

Schon mal überlegt wie viele Server weltweit auf Unix / Linux Kernel laufen?

Server verwenden UNIX und nicht Linux und, bis auf wenige Ausnahmen, AMD EPYC, Intel Xeon, IBM POWER9, usw. Sonst würde es bereits entsprechende Meldungen geben.

Die Amazon EC2 z.B. setzt auf AMD Epyc und Intel Xeon, sowie ARM AWS Graviton - Amazon EC2-Instance-Typen.

 

[Web-Schecki]

Server verwenden UNIX und nicht Linux

Nö, natürlich gibt's zahlreiche Server mit Linux und ich glaube das ist sogar die absolute Mehrheit.

Zweitens liefert RDRAND nach Spezifikation kryptographisch verwertbaren Output
[...]
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.

Also zumindest im Linux-Kernel ist RDRAND nur eine Entropiequelle von vielen. Würde mich wundern, wenn die Sicherheit davon beeinträchtigt wird, weil genau das schon vor längerem diskutiert wurde, als es die Vermutung gäbe, Intel hätte in RDRAND eine backdoor eingebaut. Da wurde viel diskutiert und versichert, dass ein unsichere RDRAND kein Problem darstellt.

Im Zuge der Diskussion gab es auch die Empfehlung, für kryptographisch sichere Zufallszahlen sollte man sich nie auf nur eine Quelle verlassen und schon gar nicht auf eine HW-Blackbox. Klar, wer es trotzdem tut, hat spätestens jetzt ein Problem. Wer /dev/urandom/ o.Ä. nutzt, sollte keine Probleme bekommen.
So hab ich es zumindest verstanden.