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

[Stormfirebird]

da dort der ryzen 5 2600 nur bis UEFI soundso supportet wird

Steht das irgendwo explizit oder hat du zufällig ein Asrock Board wo dran steht dass es nicht empfohlen ist ein Update einzuspielen?

 

[Engaged]

Steht das irgendwo explizit oder hat du zufällig ein Asrock Board wo dran steht dass es nicht empfohlen ist ein Update einzuspielen?

Müsste ich gleich mal nachschauen was das genau ist.
Beim Zusammenbauen musste ich auch mit ein RAM Riegel erstmal arbeiten, und ein BIOS downgrade machen.
Da steht wenn man eine zu hohe Version flasht dass man dann aber auch nicht mehr zurück kann.
Kann aber gut sein dass es ein AS Rock ist. 😅

 

[0x8100]

Mich auch. Und wo auf dem DIE sitzt denn dieser speicher? Habe den bei DIE-Shots nie wahrgenommen.

microcode-updates werden nicht dauerhaft auf der cpu gespeichert. sie werden immer dynamisch geladen - entweder beim systemstart durch das bios oder zur laufzeit durch das os.

 

[Wattwanderer]

Was musst du denn groß einstellen? Wenn du OC betreibst wäre es sowieso sinnvoll neu auf Stabilität zu testen.

So häufig mache ich das zum Glück nicht. Was andererseits bedeutet, dass ich alle Menüpunkte durchklicken muss selbst wenn sich herausstellt es muss nichts geändert werden.

Spontan fallen mir ein:

RAM Timing das immer auf Mindestwert zurückgesetzt ist obwohl sie via SPD eigentlich auslesbar sein sollte, Kram für Virtualisierung, CSM aus, iGPU abschalten weil ich es mit VMware nicht stabil zum laufen bekomme, WOL Setting, Ser Schnittstelle aus, TPM, verhindern, dass Windows die Asus App herunterladen will, Aura LEDs aus, Lüfter auf leise...

Jedenfalls kommt am Ende eine ganze Seite an Änderungen zusammen wo Asus BIOS mich fragt ob ich diese Änderungen auch wirklich speichern will.

Ist halt nervig wenn die Rechner an unterschiedlichen Standorten stehen und einige ohne Tastatur/Display betrieben werden. Flashen lassen sie sich ja nur mit einem USB Stick. Wäre schön wenn sie nach dem Flashen nicht ins BIOS booteten wo man alles einstellen muss und erst dann das OS bootet.

 

[DevPandi]

Das macht man nur dann wenn man etwas patcht was eine derbe Lücke ist.

Nein, nicht wirklich. Bei µCode ist es eher genau andersherum: Je derber die Lücke oder der Bug ist, umso eher wird es in den Changelogs erwähnt, weil man dann weiß, wie wichtig das Update ist.

Service-Updates, die kleinere Fehler beheben oder auch den Ablauf in der CPU verbessern, lässt man unerwähnt, weil man damit ggf. zu viele Informationen der Konkurrenz gibt.

Malware den Microcode der CPU beschreiben könnte.

Theoretisch ja, praktisch eher weniger, da die Microcode-Updates signiert werden und wenn die Signatur nicht passt, lädt die CPU die Updates nicht.

Man muss schon an den Hauptschlüssel von AMD, Intel und Co kommen, um genau das zu machen.

Macht die Heimlichtuerei überhaupt Sinn?

Ja, weil man mit kleineren Updates der Konkurrenz Anhaltspunkte liefert, mit denen die Konkurrenz Techniken in den CPUs erkennt und selbst nutzen kann usw.

Der Microcode liegt vermutlich als binary vor, aber es wird nicht lange dauern bis den jemand dekompiliert und grob weiß, was die Änderungen sind oder sehe ich das falsch?

Theoretisch, dafür musst du aber auch die vorherige Version decompilieren und prüfen und so schlau wird man da heute nicht mehr drauß.

Kann natürlich auch sein, dass man nichts zu verbergen hat und das schlicht Änderungen sind, die nicht groß der Rede wert sind.

Das ist es eher.

Das ist aber sehr häufig bei solchen kleinen Meldungen der Fall.

Ist ja nicht so, als könnte man bei solchen Meldung wirklich kreative Arbeiten.

Mich auch. Und wo auf dem DIE sitzt denn dieser speicher? Habe den bei DIE-Shots nie wahrgenommen.

und @sikarr eigentlich keiner mehr. Der µCode wird heute in der Regel in einer RAM-Area der CPU abgelegt und von dort auch dann verarbeitet. Früher gab es zwei "wege" entweder man hat den µCode relativ fest in die CPU gebrannt - was AMD sehr sehr lange gemacht hat - oder eben in einem ROM abgelegt und von dort dann geladen. Führte dann aber dazu, dass Fehler in einem Prozessor erst mit einem neuen Stepping oder eben später in neuren Revisionen der CPU ausgeliefert wurden, die dann bereits den neuen µCode in ihrer ROM hatten.

Heute wird der µCode im BIOS abgelegt und von dort beim Booten in den RAM-Area der CPU geladen und dann ausgeführt. Das Betriebssystem hat auch einen Weg in den RAM und kann auch den µCode updaten.

 

[Tanzmusikus]

kann man das Microcode Update auch anders einspielen?

Wie schon erwähnt -> per Betriebssystem. Nutzt Du also ein aktuelles, dann ist es wahrscheinlich bald aktiv.

Früher mit ungesicherten BIOS-Versionen ging das auch manuell (AMI, Award, Phönix, usw.) zu editieren.
Habe selbst Microcodes vom 771er Intel-Board auf einem 775er installiert, damit der E5450 auf dem 775er Board läuft. Und er läuft immer noch damit ... 😉

 

[Engaged]

Wie schon erwähnt -> per Betriebssystem. Nutzt Du also ein aktuelles, dann ist es wahrscheinlich bald aktiv.

Früher mit ungesicherten BIOS-Versionen ging das auch manuell (AMI, Award, Phönix, usw.) zu editieren.
Habe selbst Microcodes vom 771er Intel-Board auf einem 775er installiert, damit der E5450 auf dem 775er Board läuft. Und er läuft immer noch damit ... 😉

Alles klar dann mache ich lieber nichts, auf der Kiste läuft Windows 11. 😅

 

[der Unzensierte]

Mein Gott - es ist nur ein Microcode-update. Wie das läuft hat @Tanzmusikus in #41 schön erklärt. Das außergewöhnliche (und deshalb der Artikel) ist das ausrollen für alle Ryzen. Und was hier wieder alles reininterpretiert wird.

Meiner Meinung nach

sollte man überlegen wie dann ein Microcode-update in die fertige hardware kommen soll bevor man postet.

 

[DevPandi]

Früher mit ungesicherten BIOS-Versionen ging das auch manuell (AMI, Award, Phönix, usw.) zu editieren.

Jaein ... das Bild was du da mit weckst ist etwasa verfälscht.

Habe selbst Microcodes vom 771er Intel-Board auf einem 775er installiert, damit der E5450 auf dem 775er Board läuft. Und er läuft immer noch damit ... 😉

Du hast den µCode nicht wirklich bearbeitet/editiert, sondern du hat den µCode-Blob von einem Mainboard und Sockel in ein anderes Mainboard gesetzt. Was damals wirklich sehr einfach ging.

Aber auch damals hat Intel schon die µCode-Updates signiert und wenn man da was geändert hat, ging es in der Regel nicht mehr, weil die Signatur des Updates nicht mehr passt und die Prüfung beim Laden fehlschlägt.

 

[Hannibal Smith]

...sollte man überlegen wie dann ein Microcode-update in die fertige hardware kommen soll bevor man postet.

stimmt ... es gibt ja keine anderen Wege wie über ein BIOS Update oder so. Sorry aber dieser Kommentar von dir kling so unglaublich arrogant.

 

[VIIV]

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?

https://www.deskmodder.de/blog/2022/03/02/agesa-1-2-0-6b-und-ein-selbstversuch/

Die Alternative?

Entweder in den sauren Apfel beißen und das Update machen,
oder es sein lassen, mit dem unguten Gefühl, eventuell ein Scheunentor zu haben!

Aber um ein BIOS-Loch nutzen zu können, müsste der Angreifer auch schon Zugriff
auf die Maschine (Computer) haben. Von daher, ...
(Ist vielleicht für Firmen von Bedeutung, aber privat?)

Wobei ich es eher nicht glaube, dass mit dem Update ein Loch gepatcht wird!
Was hier so spekuliert wird, tztztz.

Es hat eher mit der Unterstützung der neuen CPU's zu tun, im Speziellen mit dem
AMD Ryzen 7 5800X3D.

Wer sich da aber nicht so sicher ist, kann ja einfach auf den Supportpages der
Mainboardhersteller nach schauen, was da so zu den BIOS-Updates steht.

 

[Dome87]

Na vielleicht haben sie jetzt endlich mal die nervige WHEA-Problematik ausgebügelt. Aber das wird wohl erst mit ZEN 4 so weit sein (hoffentlich...)

 

[der Unzensierte]

Sorry aber dieser Kommentar

trifft wenn es hoch kommt 10% aller im Umlauf befindlichen System - der Rest bekommt nie auch nur ein BIOS-Update. Manche lassen die auch bewusst weg - so wie ich die mit AGESA 1.2.0.6B. Die normalen user lässt du also links liegen. Soviel zum Thema Arroganz.

 

[DevPandi]

Sorry aber dieser Kommentar von dir kling so unglaublich arrogant.

Ach, ich hab das manchmal auch drauf. So richtig schön ARROGANT! Da macht doch der Tag erst Spaß!

Allgemein muss man sich aber bei µCode-Updates weniger Sorgen machen. Die CPU hat selbst heute einen kleinen ROM, in dem RSA-Schlüssel abgelegt werden - in der Regel die öffentlichen Keys zur, zur Prüfung. Bevor ein µCode-Blob in die Freiheit entlassen wird, wird der Blob mit dem privaten Key beim Hersteller signiert und die Signatur mit gegeben. Signatur + Blob verschmelzen quasi zu einem neuen Blob.

Wenn man nun den µCode-Blob in die CPU laden will, wird erst mal die Signatur geprüft, wenn diese passt: Okay, ansonsten: Nö!

Das ist jetzt kein 100 % Schutz, geht nicht, aber vergleichsweise sicher. Da ist ein BIOS/UEFI schon eher anzugreifen.

Aber um ein BIOS-Loch nutzen zu können, müsste der Angreifer auch schon Zugriff
auf die Maschine (Computer) haben.

Oh, das sollte man so nicht sagen. Auch wenn es immer schwerer wird, aber für so manche UEFI/BIOS-Manipulationen braucht man keinen Zugriff auf die Maschine - keinen physchen. Es reicht schom, wenn man über andere Bereiche hinein geht. Besonders prominennt sind die Managment-Enginens. Genau so reicht es manchmal aber auch, wenn man über Windows und Co geht und sich da wieder was öffnet.

Es wird schwieriger, aber die Komplexität der heutigen Rechner führt dazu, das da auch einige Wege offen stehen.

 

[feidl74]

Na vielleicht haben sie jetzt endlich mal die nervige WHEA-Problematik ausgebügelt. Aber das wird wohl erst mit ZEN 4 so weit sein (hoffentlich...)

welche Problematik gibt es da aktuell?

 

[Dome87]

Bitte googeln

 

[VIIV]

... Da ist ein BIOS/UEFI schon eher anzugreifen.

Oh, das sollte man so nicht sagen. Auch wenn es immer schwerer wird, aber für so manche UEFI/BIOS-Manipulationen braucht man keinen Zugriff auf die Maschine - keinen physchen. Es reicht schom, wenn man über andere Bereiche hinein geht. Besonders prominennt sind die Managment-Enginens. Genau so reicht es manchmal aber auch, wenn man über Windows und Co geht und sich da wieder was öffnet.

Es wird schwieriger, aber die Komplexität der heutigen Rechner führt dazu, das da auch einige Wege offen stehen.

Bei Deinem zweiten Szenario ist das BS aber schon kompromittiert.
Da ist das Kind ehe schon in den Brunnen gefallen.
Aber mal ganz davon ab, solch komplexe Angriffe werden in der Regel nicht auf Rechner von Hinz und Kunz durchgeführt!
Also ist ein Sicherheitsrisiko für Privat eher theoretischer Natur.

Und wer benutzt im Privaten "Managment-Enginens"?

Also, alles nur halb so wild für Lieschen Müller und Hugo Egon Balder.

 

[Tanzmusikus]

Jaein ... das Bild was du da mit weckst ist etwasa verfälscht.

Was meinst Du?
Ich konnte die BIOS-Versionen verändern, indem ich bestimmte Option-ROMs entfernt, ausgetauscht oder hinzugefügt habe.

Du hast den µCode nicht wirklich bearbeitet/editiert, sondern du hat den µCode-Blob von einem Mainboard und Sockel in ein anderes Mainboard gesetzt. Was damals wirklich sehr einfach ging.

Hab ich auch nicht geschrieben. Lies Dir meinen Text nochmals in Ruhe durch.
"BIOS verändern" ungleich "µCode verändern".

Aber auch damals hat Intel schon die µCode-Updates signiert und wenn man da was geändert hat, ging es in der Regel nicht mehr, weil die Signatur des Updates nicht mehr passt und die Prüfung beim Laden fehlschlägt.

Meinst Du vielleicht die Checksumme vom gesamten BIOS ... bzw. im einzelnen µCode für jeden Prozessor?

Oder meinst Du wirklich eine aufwändige Signatur-Prüfung?
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.

Eine Checksum/Prüfsumme war auch damals in vielen Fällen bereits vorhanden. Ist nix Neues.
Auf Mac-Geräten müssen sogar Grafikkarten mit entsprechenden Blob-Teilen "signiert" werden.

Eine BIOS-Checksumme kann man bei älteren Boards relativ leicht anpassen, wenn man weiß wie. 😉

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.

Seit AM4 lassen sich z.B. bei ASRock-Boards nicht mehr einfach so veränderte BIOS/UEFI-Versionen flashen.
Davor ging es bisher immer problemfrei.

Bei ASUS war das schon länger der Fall, allerdings sind da die Aushebelungsmethoden auch besser bekannt.

Grüße

 

[Discovery_1]

Wenn ich dafür eine neue Bios-Version neu aufspielen muss, nein Danke. Never change a running system.

 

[Hejo]

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.