News AMD: Neuer CPU-Microcode für Ryzen mit Zen 1, 2 und 3

VIIV schrieb:
Und wer benutzt im Privaten "Managment-Enginens"?
Naja, die sind nunmal in allen modernen x86-Plattformen mit drin, nicht deaktivierbar und laufen, sobald der Rechner Strom hat - ob du von den Funktionen nun aktiv Gebrauch machst, oder nicht. Das ist ja gerade ein großer Kritikpunkt daran. Wie so oft bietet Wikipedia einen hervorragenden Überblick über das Thema.
Hat aber mit diesem Patch nicht direkt etwas zutun.

Discovery_1 schrieb:
Wenn ich dafür eine neue Bios-Version neu aufspielen muss
Musst du nicht.
Hejo schrieb:
Hier geht es nicht um ein BIOS-Update.
 
Ah ! AMD verteilt ein "Easter Egg" ....:vernaschen:
 
  • Gefällt mir
Reaktionen: dev/random und Tanzmusikus
Web-Schecki schrieb:
Hat aber mit diesem Patch nicht direkt etwas zutun.
Indirekt! Es ging mir darum, dass Untervolter oder Übertakter die Finger von einem BIOSUpdate besser lassen sollten.
Die sollten diesen Flicken lieber vom BS stopfen lassen.
;)
 
  • Gefällt mir
Reaktionen: Engaged, dev/random, MGFirewater und 5 andere
Viper816 schrieb:
Möglicherweise habe ich da was nicht mitbekommen. Wärst Du so freundlich mich und andere aufzuklären warum das Update ein Problem ist für OC und UV?

Was ist dann die Alternative? Nie mehr updaten?
Bei meinem Asus Crosshair VIII wird die CPU Spannung begrenzt. Um genau zu sein: Wenn man übertaktet und den EDC größer als 140A stellt, bekommt man keine 1,5V mehr auf der CPU, sondern nur noch max. 1,425 und die Single Core Boost Leistung sinkt spürbar im Benchmark. Eine Umgehung ist zwar mit positivem CPU Offset möglich, hat aber bei mir praktisch zu nichts geführt. Die MultiCore Performance ist aber bei mir mit 180A EDC deutlich besser.
Also Qual der Wahl: gute Single Core Performance mit EDC 140 oder mehr Multicore mit EDC 180. Beides zusammen, wie bei BIOS Varianten vor 39xx, geht nicht. Insgesamt ist die CPU trotz der Übertaktung und Undervolting per Curve Optimizer mit dem BIOS 4006 klar langsamer als vorher mit 3801. Ich bin Quasi zurück auf die Benchmarkwerte von Computerbase aus dem November 2020 ohne Übertaktung :-(

Also Finger Weg von BIOS >3801 (AGESA V2 PI 1.2.0.3 Patch C)

So mein jetziger Stand.
 
  • Gefällt mir
Reaktionen: MGFirewater und Viper816
mrhanky01 schrieb:
Das macht man nur dann wenn man etwas patcht was eine derbe Lücke ist.
Quasi damit keiner auf die Idee kommt es vorher auszunutzen…

aluhut glüht
Oder wenn man eine Lücke einbauen will, das liegt aktuell ja sehr im Interesse des Osten und Westen.
 
  • Gefällt mir
Reaktionen: piatnik-stmk und mrhanky01
VIIV schrieb:
Es gibt kein Weg zurück!
Gibt es eine Quelle dazu?
Ein Mainboard mit einer "Flashback" Funktion sollte doch auf eine ältere Biosversion zurückgeflasht werden können?
(Habe bei meinem Asus Crosshair VI Hero, mit der "Flashback" Funktion von Bios 8503 auf 7306 zurückgeflasht.)
 
Tanzmusikus schrieb:
Ich konnte die BIOS-Versionen verändern, indem ich bestimmte Option-ROMs entfernt, ausgetauscht oder hinzugefügt habe.
Na, BIOS früher zu verändern ist ja auch bisschen was anderes. ;) Das kann man theoretisch heute auch noch. Wenn man weiß wie!

Ich bin im übrigen bei meinem Beitrag von dem ursprünglichen Context ausgegangen, der hier angespielt wurde, dass man ja einfach µCode-Updates auf die CPU laden kann, nicht dass man das µCode-Blob im BIOS austauscht. Daher da auch mein Ja und Nein.
Tanzmusikus schrieb:
Meinst Du vielleicht die Checksumme vom gesamten BIOS ... bzw. im einzelnen µCode für jeden Prozessor?
Kommt jetzt darauf an. Ich weiß das jede Signatur eine Checksumme ist, aber nicht jede Checksumme ist eine Signatur. ;)

Ich meine in dem Fall aber nicht die Checksummen perse, sondern die signierten µCode-Blobs. Gut ich muss dazu schreiben, dass ich jetzt nicht weiß, wie Intel damals vorgegangen ist bei den µCode-Blobs und wie sie diese geprüft haben. Ich hoffe gerade inständig, dass sie damals nicht nur Prüfsummen geprüft haben und dann ab die Lutzi, das wäre ja fatal!
Tanzmusikus schrieb:
Selbst wenn, diese Signatur wird man mit dem Hex-Editor sicherlich sehr genau ausfindig machen können, gerade, da sie immer gleich sein muss, um erkannt zu werden.
Also, eine Signatur die mit einem entsprechenden Schlüssel erstellt wird, die bearbeitest du nicht so einfach mit einem Hexeditor. Wenn du das schaffst, echt Hut ab! Dann würde ich dir hier sofort einen Arbeitsvertrag schicken, weil dann brauch ich dich hier!

Eine Signatur muss nicht immer gleich sein um erkannt zu werden - zumindest jetzt nicht, wenn ich dich richtig verstehe. Eine Signatur dient dazu um die Echtheit eines Dokumentes zu prüfen und natürlich darf sich die Signatur auch ändern und sie muss sich sogar für jedes Dokument ändern.

Eine Signatur - jetzt stark vereinfacht - erstellst du in dem Fall in dem du erst mal eine Checksumme/Prüfsumme des Blobs erstellst und dann diese Prüfsumme mit deinem Schlüssel "verschlüsselst" und dann anhängst. Die Gegenseite trennt nun erst mal die Signatur vom Blob und errechnet dann die Prüfsumme des Blobs und mit dem eigenen Schlüsse wird die Signatur entschlüsselt und dann die Prüfsummen verglichen. Wenn nun ein Bösewicht den Blob änderte, dann merkt man das an der Stelle, weil die Prüfsummen nicht mehr stimmen.

Du kannst versuchen die Signatur per Hex-Editor anzupassen, aber solange du den Schlüssel nicht hast, mit dem die Signatur erstellt wurde, dürfte dir das schwer fallen.

Tanzmusikus schrieb:
Eine BIOS-Checksumme kann man bei älteren Boards relativ leicht anpassen, wenn man weiß wie.
Ja, das kann man, sofern es einfache MD5, SHA1 und Co Prüfsummen waren, die nicht signiert wurden. Bei signierten Prüfsummen sieht das anders aus.
Tanzmusikus schrieb:
Was zunehmend immer mehr passiert ist, dass ein BIOS/UEFI-Update sehr stark vor Veränderung abgesichert wird. Es werden also längere "Checksummen" bzw. aufwändigere Sicherungsmethoden angewandt.
Ja, die Verfahren für die Checksummen werden aufwendiger, aber Checksummen alleine kann man ja anpassen. Sobald man den Hash-Algorithmus kennt, der die Checksumme berechnet, ist quasi der Vergleich alleine verloren.

Es gibt halt zwei Methoden, die man hier anwenden kann: Man verschlüsselt den Blob als ganzes oder man verwendet eben eine digitale Signatur, die die Checksumme des eigentlichen Blobs verschlüsselt. Deswegen gibt es ja in Zen die eine ARM-Enklave, die dafür zuständig ist. AMD hat in dem ARM-Chip verschiedene Schlüssel hinterlegt, mit denen man entweder den Blob als ganzes oder eben die Checksumme entschlüsselt und dann prüfen kann.

Ich gehe sogar davon aus, dass AMD in Zen nicht den Blob als ganzes Verschlüssselt, sondern nur die Checksumme, weil das dann viel schneller geht.

Ebenso wird AMD vermutlich auf RSA-Schlüsselpaare setzten, weil man dann zwar die "öffentlichen" Schlüsse in der CPU gerne auslesen kann, aber damit nicht viel anfangen kann. Der Primärschlüssel wird AMD - hoffentlich - gut abgelegt gespeichert haben und nur rausholen, wenn er benötigt wird, am besten auf Hardwaretokens die irgendwo unter Verschluss sind. :)
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Nein, über Windows Update und auch als BIOS Update Version (sofern der Board Hersteller es ausliefert)
 
bytzmaster schrieb:
das bedeutet, dass das update über dei radeon software kommt?
Nein, die Grafiksoftware von AMD hat damit nichts zu tun. Es geht hier um den Haupt-Prozessor.
Das Update kommt entweder manuell installiert als UEFI/BIOS auf einen BIOS-Chip des Mainboards ... oder per Betriebssystem, wo der Microcode nur im Hintergrund in den Arbeitsspeicher geladen wird.

DevPandi schrieb:
Na, BIOS früher zu verändern ist ja auch bisschen was anderes. ;)
Das kann man theoretisch heute auch noch. Wenn man weiß wie!
Ja, verändern kannst Du die heutigen UEFI/BIOS-Dateien auch, aber Du musst dann schauen, ob und wie Du eine solch veränderte Firmware auch in den Chip auf dem Mainboard geflasht bekommst. ;)

DevPandi schrieb:
Ich bin im übrigen bei meinem Beitrag von dem ursprünglichen Context ausgegangen, der hier angespielt wurde, dass man ja einfach µCode-Updates auf die CPU laden kann, nicht dass man das µCode-Blob im BIOS austauscht. Daher da auch mein Ja und Nein.
"auf die CPU laden" verstehe ich nicht, weil zu ungenau beschrieben. Ist ja keine Wärmeleitpaste. :daumen:
Außerdem hatte ich Beides beschrieben: per OS & per BIOS-Flash.

DevPandi schrieb:
Du kannst versuchen die Signatur per Hex-Editor anzupassen, aber solange du den Schlüssel nicht hast, mit dem die Signatur erstellt wurde, dürfte dir das schwer fallen.
Jap, da hast Du Recht.

DevPandi schrieb:
Ja, die Verfahren für die Checksummen werden aufwendiger, aber Checksummen alleine kann man ja anpassen. Sobald man den Hash-Algorithmus kennt, der die Checksumme berechnet, ist quasi der Vergleich alleine verloren.
Das konnte ich sehr gut verstehen. Danke dafür! Habe was dazu gelernt.

Grüße
 
Hannibal Smith schrieb:
Meiner Meinung nach sollten Betriebssysteme nicht mal die Möglichkeit haben auf den microcode schreibend zuzugreifen. Wo wären wir denn, wenn jede billige Malware den Microcode der CPU beschreiben könnte. Wären damit nicht sogar Clean Installs nutzlos?

Naja, AMD wird sich was dabei gedacht haben und dass der Microcode via Windows/ Linux-Kernel verteilt wird, ist nicht sicher, wenn ich das richtig gelesen habe.
Ich hoffe und vermute doch, dass die Microcodes signiert sind...
 
mrhanky01 schrieb:
Jo, und wie wir wissen, kann das ganz schnell ins Auge gehen:
"Dann bedarf es nur noch eines kleinen Sprühens sozusagen, in die gludernde Lot..."

Ich hoffe doch und erwarte auch, dass AMD noch Infos nachreicht. Bis dahin gehe ich davon aus, dass fiese Löcher gefixt wurden.
 
  • Gefällt mir
Reaktionen: mrhanky01
Nein, die µCode-Updates sind generell erstmal unabhängig davon.
Sie werden wahrscheinlich auch als Windows Updates erscheinen.

Könnte aber zusätzlich in die UEFIs mit AGESA 1.2.0.7 hinzugefügt werden, da diese ja auch für alle Ryzen-Genrationen zur Verfügung gestellt werden sollen. Läge also nah beieinander & würde sogar Sinn machen!

Wir werden sehen ...
 
  • Gefällt mir
Reaktionen: dev/random und MGFirewater
Möglicherweise ist es irgendeine Lücke die sich noch im "Disclosure" (CVD) befindet und einfach stillschweigend gepatcht wird, bevor die "nuke" später dann durch die Nachrichten gezündet wird.
 
  • Gefällt mir
Reaktionen: Engaged und MGFirewater
VIIV schrieb:
Übertakter und solche, die untervolten, Finger weg!

1. Update AMD AM4 AGESA V2 PI 1.2.0.6b

Es gibt kein Weg zurück!

Wer jedoch vorhat, einen AMD Ryzen 7 5800X3D einsetzen zu wollen, wird nicht
drumherum kommen.
agesa 1.2.0.7 soll z.b den vddg bug (0,9999v limit beheben) gerade darauf warten viele die deswegeb keine flck von 1900mhz und mehr erreichen (ich bin nicht betroffen) nur das curve optimizer setting mit agesa 1.2.06b hakt bei mir, weshalb ich zurück zu agesa 1.2.3 patch c bin.
Ergänzung ()

Hejo schrieb:
Kein Bock alles wieder neu einzustellen beim letzten BIOS-Update musste ich das Speicher-OC vollständig neu ausloten. Die Mainboard-Hersteller schreiben doch selber immer auf der Homepage oder im Handbuch wenn alles läuft und es nicht zwingend notwendig ist (z.B. neue CPU), Finger weg.
also mein ram oc läuft mit allen agesas & beta bios versionen, wenn ich instabilitäten bekomme dann allein über curve optimizer & core boost.

und das ist relativ scharf. aber das limit bei mir sind defintiv meine ballistix und nicht der chipsatz oder die cpu

f14c ist agesa 1.2.0.3c, f15a ist agesa 1.2.0.6b
Ergänzung ()

Sysworker schrieb:
Bei meinem Asus Crosshair VIII wird die CPU Spannung begrenzt. Um genau zu sein: Wenn man übertaktet und den EDC größer als 140A stellt, bekommt man keine 1,5V mehr auf der CPU, sondern nur noch max. 1,425 und die Single Core Boost Leistung sinkt spürbar im Benchmark. Eine Umgehung ist zwar mit positivem CPU Offset möglich, hat aber bei mir praktisch zu nichts geführt. Die MultiCore Performance ist aber bei mir mit 180A EDC deutlich besser.
Also Qual der Wahl: gute Single Core Performance mit EDC 140 oder mehr Multicore mit EDC 180. Beides zusammen, wie bei BIOS Varianten vor 39xx, geht nicht. Insgesamt ist die CPU trotz der Übertaktung und Undervolting per Curve Optimizer mit dem BIOS 4006 klar langsamer als vorher mit 3801. Ich bin Quasi zurück auf die Benchmarkwerte von Computerbase aus dem November 2020 ohne Übertaktung :-(

Also Finger Weg von BIOS >3801 (AGESA V2 PI 1.2.0.3 Patch C)

So mein jetziger Stand.
kann ich bestätigen. wobei die performacne von 1.2.0.6b quasi der ursprungsperformance von 1.2.0.0 entspricht. mein5800x hatte in cbr20 zu beginn um diet 58xxpt, ging dann rauf bis auf 61xx und wäre jetzt mit agesa 1.2.0.6b wieder rgendwas um die 59xx pt
 

Anhänge

  • f14c.png
    f14c.png
    41,3 KB · Aufrufe: 180
  • f15a.png
    f15a.png
    41,3 KB · Aufrufe: 178
Zuletzt bearbeitet:
Zurück
Oben