Ryzen 3000: Bug zwingt Linux und Windows in die Knie - BIOS-Update soll helfen

Jetzt ist Ihre Meinung gefragt zu Ryzen 3000: Bug zwingt Linux und Windows in die Knie - BIOS-Update soll helfen

Mittels eines BIOS-Updates will AMD die Problematik rund um den Start-Bug der neuen Ryzen 3000-Prozessoren beheben. Die Mainboard-Hersteller müssen den neuen Code nun einbauen, testen und dann an die Nutzer verteilen.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Ryzen 3000: Bug zwingt Linux und Windows in die Knie - BIOS-Update soll helfen

Von dem Bug hatte ich schon die Tage gelesen. Das jetzt auch noch Windows betroffen ist macht mich wahnsinnig. Nun nochmals ein Update obwohl die Mainboardhersteller mit ihren Bios Versionen sowieso nicht voran kommen und nur Beta Bios hier und gar kein Bios dort und Fehler trotz Beta Bios da drüben

Das kann den Launch ganz schön schädigen. Bei den vielen potentiell geeigneten Boards, ist es ja jetzt schon kompliziert.

Solavidos schrieb:

Von dem Bug hatte ich schon die Tage gelesen. Das jetzt auch noch Windows betroffen ist macht mich wahnsinnig. Nun nochmals ein Update obwohl die Mainboardhersteller mit ihren Bios Versionen sowieso nicht voran kommen und nur Beta Bios hier und gar kein Bios dort und Fehler trotz Beta Bios da drüben

Zum Vergrößern anklicken....

Estmal alles lesen bevor man wahnsinnig wird.
Unter Windows gibt es nur bei Destiny 2 Probleme. Zumindestens ist von mehr nichts bekannt bis jetzt.

Kryptografische Anwendung sind möglicherweise auch betroffen. Denn die haben dann keinen Zufall mehr in den Schlüsseln.
Eine Backdoor für die NSA, die Nebenwirkungen hatte?

DKK007 schrieb:

Kryptografische Anwendung sind möglicherweise auch betroffen. Denn die haben dann keinen Zufall mehr in den Schlüsseln.

Zum Vergrößern anklicken....

Zumindest nach meinem Stand aktuell nur die, die auf von der CPU generierte Zufallszahlen zurückgreifen. Tools die DAS tun halte ich ohnehin nicht für sonderlich sicher (bzw. nur für zeitlich sehr begrenzte Verschlüsselungen sinnvoll), da gibts wesentlich "zufälligere" Methoden. VeraCrypt nutzt beispielsweise den Mensch der beim Generieren der Zufallszahl seine Maus nach seinem Gutdünken eine Weile/Strecke bewegen soll... das generiert schon wirklich SEHR zufällige Hashes. Dass jemand pixelgenau einen Weg errät den jemand anders mit seiner Maus gezogen hat ist schon hart unwahrscheinlich.

DKK007 schrieb:

Kryptografische Anwendung sind möglicherweise auch betroffen. Denn die haben dann keinen Zufall mehr in den Schlüsseln.

Zum Vergrößern anklicken....

RDRAND direkt vom Prozessor als Quelle für Zufallszahlen zu benutzen, ist definitiv unsinnig - dafür gibt es getentropy() als Wrapper im Kernel. Im Gegensatz zu getrandom() blockt getentropy() auch nicht, sollte nicht genügend Entropie vorhanden sein.

Den random number generator von Cloudflare find ich immer noch am besten: The Lava Lamps That Help Keep The Internet Secure

Namaker schrieb:

Im Gegensatz zu getrandom() blockt getentropy() auch nicht, sollte nicht genügend Entropie vorhanden sein.

Zum Vergrößern anklicken....

Au ja, super. Wenn wir als Zufallszeichen FFFFFFFFFFFFFFFFFFFFFFF herausbekommen, machen wir dann einfach weiter, ja? Weil es ja doof wäre, wenn man warten muss...

Dass das System geblockt hat, weil die Zufallszahlen nicht OK waren, war das einzig richtige. Es ist zu hoffen, dass das Problem per Update wirklich restlos gelöst wird. AMD hat auch Dinge wie RAM-Verschlüsselung an Board, die nötig ist, um verschiedene Angriffe wie Rowhammer abzuwehren.

Nuallan schrieb:

Den random number generator von Cloudflare find ich immer noch am besten: The Lava Lamps That Help Keep The Internet Secure

Zum Vergrößern anklicken....

Danke das wusste ich noch nicht.

Das ist natürlich ärgerlich, aber kann bei solchen Launches passieren.

Headcrash schrieb:

Das ist natürlich ärgerlich, aber kann bei solchen Launches passieren.

Zum Vergrößern anklicken....

Das kann nicht passieren, das passiert definitiv immer.
Jede moderne CPU hat Hunderte (!) Bugs, das ist völlig normal. Nur ab und zu kommts vor dass einer der Bugs für den Endanwender tatsächlich relevant wird oder "größer" ist. Prominente Beispiele fetter Bugs: TLB-Bug beim Phenom, Spectre/Meltdown/..., FDIV-Bug des Pentium,...

Incredible Alk schrieb:

Das kann nicht passieren, das passiert definitiv immer.
Jede moderne CPU hat Hunderte (!) Bugs, das ist völlig normal. Nur ab und zu kommts vor dass einer der Bugs für den Endanwender tatsächlich relevant wird oder "größer" ist. Prominente Beispiele fetter Bugs: TLB-Bug beim Phenom, Spectre/Meltdown/..., FDIV-Bug des Pentium,...

Zum Vergrößern anklicken....

Die sind ja auch sehr komplex. Bei sovielen Transistoren und Schaltungen.
Ich hatte mal früher Mechatroniker Umschulung gemacht. Da hatten wir das angeschnitten.
Logische Schaltungen, Gatter usw.
Ich will nicht wissen wie groß oder wieviele Schaltpläne das bei modernen CPUs sind.
Das die Ingeneure da noch den Überblick behalten.

Da hat keiner mehr den Überblick, seit Jahrzehnten schon nicht mehr. Kein Mensch ist in der Lage, Abermillionen von Transistoren funktionierend anzuordnen - hier gilt schon lange Maschinen bauen Maschinen. Bedeutet Ingenieure erfinden die theoretischen Hintergründe der Architekturen und greifen auf "Baukästen" zurück. Dann wird virtuell ein Chip nach Baukasten simuliert der nen Quadratmeter groß wäre. Was wir am Ende sehen, also dicht gepackte und ultrakomplexe Anordnung von Milliarden Transistoren auf der Fläche eines Fingernagels ist das Ergebnis von zigtausenden Stunden Rechenleistung, wo Computer iterativ das Transistorlayout der CPU optimieren - das kann kein Mensch mehr von Hand machen.

Deswegen ists beispielsweise auch kein großer (entwicklungstechnischer) Aufwand für einen Hersteller, bei einer bestehenden Mehrkerncpu einfach noch 2 Kerne dazuzubauen. Die Architektur und der Baukasten und die Optimierung ist schon da - wenn man dem Programm sagt mach x Kerne mehr dazu spuckts ein Layout für eine entsprechende CPU aus. Intel könnte innerhalb eines Tages einen 9901K bringen der 12 oder 14 oder 20 Kerne hat - theoretisch. Was lange dauert ist die ganze Produktionskette, Sampling, Specs, Tests usw. - die eigentliche Anweisung welcher Transistor wo hin soll ist hier nicht das Problem.

Arkintosz schrieb:

Au ja, super. Wenn wir als Zufallszeichen FFFFFFFFFFFFFFFFFFFFFFF herausbekommen, machen wir dann einfach weiter, ja? Weil es ja doof wäre, wenn man warten muss...

Zum Vergrößern anklicken....

Blocken heißt in dem Fall nicht nur warten, sondern fehlschlagen. RDRAND ist auch nur eine von mehreren Quellen, die vom Kernel benutzt werden, und dazu auch nicht unumstritten.
AMD hat natürlich etwas falsch gemacht, aber die Leute von systemd hätten von vornherein nicht die Instruktion direkt aufrufen sollen.

Was hätten sie sonst machen sollen?

z.b. Hatte mal auch wenn es nix zur sache tut ne Grafikarte von Nvidia dazu gab es keine Untersützung von dem Ubuntu 18.04 (glaube das war es k.a. kann auch 16.04 gewessen sein). Wass war ich habe Treiber installiert und dann die kernels nachträglich mit den Grafikarten treibern neu konfiguriert. Erst eine version später waren die 10ner karten von Nvidia in pool drine.

Und dass kann auch niemand was dafür vor allen wenn der CPU so neu ist dass gewisse dinge nicht erkannt werden oder eine optimierte neu ortnung es effektiver macht mit einer unbekannten technologie die gerade erst geschlüpft ist an probleme kommt. Dass ist halt in der Technologie so, Nicht alles ist sofort und gleich weg verfügbar sondern es gibt immer mehr oder weniger probleme mal größer mal kleiner.