[English]Kleiner Sammelbeitrag rund um BIOS- und UEFI-Updates auf Mainboard. Auf Boards mit AMD-Chips gibt es einen TPM-Bug, der weitgehend ungefixt bleibt, weil es keine Updates der Board-Hersteller gibt. Und GIGABYTE hat BIOS-Updates veröffentlicht, um Schwachstellen zu beheben.
Kein Update: AMD TPM-Bug bleibt ungefixt
In der AMD-Community gibt es seit Februar 2023 den Beitrag Baffling Windows 11 TPM Bug Is Wreaking Havoc On Some AMD Ryzen Systems zu einem TPM-Problem. Windows kann dann fTPM auf den betreffenden Plattformen nicht erkennen. Die betreffende TPM-Prüfung endet dann mit dem Fehlercode 0x80070490. Der Community-Beitrag enthält eine umfangreiche Aufbereitung und verlinkt auch Quellen von Betroffenen.
Der Bug scheint aber Besitzer von AMD-Systemen seit 2022 zu nerven. AMD hat nun Anfang Juli 2025 diesen Supportbeitrag reagiert (ist z.B. hier und hier aufgefallen). Im Beitrag gibt AMD an, dass man dieses Problem mit TPM-Firmware-Updates bereits gelöst haben. Betroffen waren bzw. sind Systeme mit Desktop- und Notebook-Prozessoren der Serien Ryzen™ 1000 – Ryzen 5000. Den Motherboard-Herstellern wurden von AMD bereits im Jahr 2022 entsprechende Fixes zur Verfügung gestellt.
Wenn der Bug also aktuell noch auftritt, heißt dies, dass die betreffenden Firmware-Updates für das Mainboard nicht eingespielt wurden. Der Ratschlag ist, sich beim Hersteller des Motherboard nach entsprechenden Firmware-Updates, die den Bug beheben, zu erkundigen. AMD merkt aber auch an, dass einige Motherboard-Hersteller sich dafür entschieden haben, diese TPM-Firmware-Updates nicht weiterzuverbreiten.
GIGABYTE BIOS-Update fixt Schwachstellen
Shawn Brink weist in nachfolgendem Tweet darauf hin, dass Hersteller GIGABYTE BIOS-Updates für seine Mainboards veröffentlicht hat, die mehrere Schwachstellen im System Management Mode (SMM), die in einigen älteren GIGABYTE/AORUS Consumer-Motherboards verwendet werden, schließen.
GIGA-BYTE Technology Co., Ltd. hat mehrere Schwachstellen in den System Management Mode (SMM)-Modulen identifiziert, die in verschiedenen älteren GIGABYTE/AORUS Consumer-Motherboards verwendet werden. Diese Schwachstellen bestehen nur auf älteren Intel-Plattformen, auf denen die betroffenen SMM-Module implementiert sind. Neuere Plattformen sind nicht betroffen.
Die erfolgreiche Ausnutzung dieser Schwachstellen kann es einem Angreifer mit lokalem Zugriff ermöglichen, seine Privilegien zu erhöhen oder beliebigen Code innerhalb der hochprivilegierten SMM-Umgebung auszuführen. Die Details hat er im ElevenForum beschrieben.
MVP: 2013 – 2016
Es wäre schön wenn noch ergänzt wird, welche CPU Generationen auf welchen Motherboard es betrifft.
Bei einer kurzen Suche, ist mir nur aufgefallen, dass beim ASrock Taichi x370 mit dem erscheinen des AM4 AGESA Combo V2 PI 1.2.0.7 der Support für Bristol Ridge(AMD A-series/Athlon X4 series) endete.
Beim X470 Taichi wird davon abgeraten, alte CPUs Ryzen 1000 und 2000 Series mit aktuellen AGESA zu betreiben. Weshalb auch immer.
————————————————
Mein Ryzen 1800X lief auch schon mal zu Testzwecken mit AGESA V2 PI 1.2.0.7. auf dem ROG Crosshair Hero VI. Das funktionierte genauso gut oder schlecht wie mit Zeitgenössischen UEFI Versionen (von 2018) mit automatischen UEFI Einstellungen. Erst mit manuellen RAM Einstellungen von damals lief es stabil.
Beim ASrock X370 Pro 4 – AMD AM4 AGESA Combo V2 PI 1.2.0.E ; BIOS Ver. 1041 Beta – besteht das Problem auch.
Früher konnte man das BIOS in seine Module zerlegen (extract) mit diesem Befehl:
cbrom215.exe asus.bin /PCI EXTRACT
Dann konnte man eines dieser Module durch ein neueres Modul ersetzen, etwa durch ein gefixtes Raid-Controller-BIOS-Modul, indem man das Haupt-Modul mit dem neuen RAID-Modul verknüpft (Merge).
cbrom215.exe 10042u.bin /PCI 4247.bin
cbrom.exe berechnete eine neue Checksumme, trug sie in das neue BIOS ein und fertig war das neue BIOS.
Anschließend konnte man das neue BIOS ganz normal flashen und es lief.
Heute kann man auch das UEFI in seine Module zerlegen, das AMD-AGESA (wo das fTPM mit drin steckt) austauschen und alles wieder mergen.
Die Mainboard-Hersteller machen im Grunde auch nichts anderes, als ihr eigenes Modul mit dem AMD-Agesa zu verbinden. Ich habe noch nie gehört, dass ein Mainboard-Hersteller im AGESA herumfummelt und dort Bytes verändert. Der nimmt einfach das fertige AGESA und "klebt" es an sein eigenes Modul dran.
Das neue gefixte AMD-AGESA kann man deswegen auch aus einem anderen UEFI eines anderen Mainboard-Herstellers extrahieren, es muss nur zum Chipsatz und Sockel passen.
Alles was fehlt ist das kleine Tool, das ein UEFI in seine Module zerlegen kann und die Module wieder mergen kann inklusive der Berechnung der Checksumme:
UEFI-Tool,
UEFIextract,
oder BIOSCreator (nicht kostenlos)
Das kann man auch scripten und ist dann kaum Aufwand.
Daher ist es umso verwerflicher, dass manche Mainboardhersteller keine UEFI-Updates anbieten, wenn AMD ein neues AGESA veröffentlicht.
split, merge, upload.
Da manche Mainboards auch ein Dual-UEFI (A und B) haben kann man auch kaum etwas kaputt flashen, denn man hat ja im Fehlerfall immer noch das andere UEFI (B) im Flash-Speicher auf das man dann umswitchen kann und damit dann das falsch geflashte UEFI (A) wieder mit dem funktionierenden UEFI-ROM (B) reparieren kann.
Auch ohne Dual BIOS dank Flashback via USB und Hardware-Button. Komplett ohne CPU im Sockel. Kennst du bestimmt auch. Es ist eine Schweinerei, was den Kunden Jahrzehnte lang grundlos vorenthalten wurde an Komfort.
> Es ist eine Schweinerei, was den Kunden Jahrzehnte lang grundlos vorenthalten wurde an Komfort. <
Grundlos? Hersteller haben sich dem Druck der Strasse gebeugt und sind dem Ruf 'billig, billig, billig' gefolgt. Jeder Betriebswirtschaftler weiss, dass das Verfügbarmachen einer solchen Funktion – wie alles andere auch – Geld kostet und den Preis treibt. Die schlussendlich dann doch einsetzende Verbreitung könnte z. B. auf die Gewährleistungsfälle reduzierende Wirkung der Funktion zurückgehen.
| Heute kann man auch das UEFI in seine Module zerlegen,
| das AMD-AGESA (wo das fTPM mit drin steckt) austauschen
| und alles wieder mergen.
Frage dazu:
Wenn man das macht, also das AGESA incl. fTPM austauscht, kommt das einem Reset des TPM gleich, also sind die darin abgelegten Daten verloren?
Das könnte dann nämlich zu nicht mehr bootenden Windows 11 Systemen führen, deren C:-Laufwerke sich im Status "Bitlocker wartet auf Aktivierung" befinden.
Oder übersehe ich da irgendwas?
Man sollte den Bitlocker-Wiederherstellungsschlüssel griffbereit haben.
Falls man die CPU tauscht und fTPM aktiv ist, dann gibt es eine Abfrage vom UEFI:
-Y für Yes Reset fTPM
-N für No Keep old TPM-Data, allerdings wird dann die fTPM-Funktion in der neuen CPU nicht aktiviert. Wenn man die alten TPM-Schlüssel wieder haben will, dann muss man auch die alte CPU einsetzen.
Die Firmware (AGESA) achtet also genau auf die korrekte CPU.
Wenn sich eines von beiden ändert, dann kann man nicht einfach so booten, wenn vorher fTPM aktiv war, weil der TPM-Schlüssel nicht freigegeben wird und dann der Bitlocker nicht entschlüsselt.
Sonst könnte man TPM einfach umgehen, indem man entweder die CPU oder das AGESA austauscht.
AGESA (AMD-Firmware) und AMD-CPU wirken wie gegenseitige Dongle.
| Man sollte den Bitlocker-Wiederherstellungsschlüssel
| griffbereit haben. […]
| Wenn sich eines von beiden ändert, dann kann man
| nicht einfach so booten […]
Dann verstehe ich auch, warum die Hersteller es scheuen, dieses TPM-Firmware-Update weiterzureichen.
Es dürfte reichlich per Bitlocker verschlüsselte Systeme geben, deren Besitzer es nicht mal ahnen, dass das System verschlüsselt ist, weil es eben auf den ersten Blick so aussieht (Bitlocker wartet auf Aktivierung). Wenn man in diesem Bitlocker Zwischenzustand das TPM-Firmware-Update durchzieht und die Warnung hinsichtlich Recovery-Key nicht ernst nimmt — man kommt in diesem Zwischenzustand aber ohnehin nicht an ihn ran — steht man anschließend ziemlich blöd da.
********************************
steht man anschließend ziemlich blöd da.
********************************
Wieso? Dann setzt man das System neu auf und nutzt für seine Daten das Backup und der Drops ist gelutscht!
*DAUs welche dazu nicht in der Lage sind machen im allgemeinen auch kein BIOS/UEFI Update!
Da stimmt wohl einiges nicht:
a)
Der Screenshot des Tweets ist falsch verlinkt, richtigerweise müsste er auf https://x.com/Shawn_Brink_MVP/status/1945486703742845341 zeigen. Ist aber egal, da der X Tweet letzlich auch nicht wirklich zielführend ist im Sinne einer Punktladung auf der Stelle bzw. den Stellen, wo es die jeweiligen einschlägigen Updates herunterzuladen gibt.
b)
Der Hot Spot "ElevenForum beschrieben" zeigt auf (1) und dort ist praktisch nur die autoritative Primärquelle (2) reproduziert.
Und damit beginnen die eigentlichen Misslichkeiten: (2) datiert vom "Jul 10, 2025" und spricht von "GIGABYTE … is releasing BIOS updates according to the following schedule. … BIOS Release Schedule … Jun. 2025." Das heisst, der Zeitplan war bereits veraltet, als GIGABYTE die Meldung rausliess. Auch aktuell ist dort nicht nachzulesen, wann die Updates denn nun tatsächlich erscheinen werden, bzw. – falls sie schon erschienen sind – an welcher Stelle sie publiziert wurden. Wenigstens ein 'Gehen Sie nach https://www.gigabyte.com/Support/Consumer/Download' hätte man erwarten dürfen.
_
(1) https://www.elevenforum.com/t/gigabyte-motherboard-bios-updates-for-multiple-smm-memory-corruption-vulnerabilities.37963/
(2) https://www.gigabyte.com/Support/Security/2302
Man findet diese BIOS Updates da, wo man sie immer findet. Auf der Gigabyte-Seite seines Mainboard-Modells unter Support / Downloads / BIOS.
Anmerkung: Der Screenshot ist bewusst nicht auf den Tweet verlinkt, sondern ich verwende bei X i.d.R. einen Link auf die im Tweet referenzierte Primärquelle. Ich muss im Blog Leser nicht auf Musks X-Plattform umleiten, wenn es nicht zwingend erforderlich ist. Ich habe im Text aber "Tweet" verlinkt.
Bei meinem Asrock Board wurde der fTPM nach einem Wechsel von einer Ryzen 3700x nach 5700x CPU auch nicht mehr für den "Nachweis als Bereit" erkannt, weil die EK-Zertifikate nicht im TPM vorhanden waren.
Nach diversen Versuchen, das Problem per Softwareeinstellungen zu lösen, habe ich dann einen passenden SPI-TPM Baustein von Asrock für rund 15 Euro erworben. Allerdings ist es mit dem Erwerb und Einbau dieses Chips nicht getan. Die Anleitung von Asrock sagt, man soll einen UEFI-bootfähigen USB-Stick mit der efi Shell erstellen und damit eine bei Asrock verfügbare Uefi-Erweiterung ins BIOS laden. Verrät aber nicht, wie es geht. Damit dürfte das für die meisten Anwender schon nicht mehr praktikabel sein.
Ich bin letztendlich bei Reddit fündig geworden, wo jemand eine funktionierende Anleitung gepostet hat: https://www.reddit.com/r/ASRock/comments/1jr1woq/installing_dedicated_spi_tpm_module_on_asrock_amd/
Damit ist jetzt Windows zufrieden und tpmdiagnostic ekinfo zeigt das Vorhandensein der EK Zertifikate an und die Details zum Sicherheitschip befinden den Status von Nachweis und Speicher als Bereit.
Vielleicht hilft das ja dem einen oder anderen Betroffenen.
Man kann allerdings derzeit mit dem Fehler leben. Bitlocker lässt sich auch dann aktivieren, wenn der Nachweis nicht bereit ist. Ist vielleicht ein Grund, warum die Boardhersteller keinen Grund sehen, die fTPM-Firmware zu aktualisieren und möglicherweise zu riskieren, dass Anwender nicht mehr an ihre Bitlocker verschlüsselten Daten herankommen, weil halt der Wiederherstellungsschlüssel nicht gesichert wurde oder aus sonstigen Gründen nicht greifbar ist.
Zumal ich es für durchaus möglich halte, dass viele Windows 11 Anwender gar nicht mitbekommen haben, dass ihre Festplatte mit Bitlocker verschlüsselt ist.
Kleiner Nachtrag:
Ich habe gestern den Asrock-Support wegen eines BIOS mit der aktuellen AMD-TPM Firmware angeschrieben. Binnen 24 Stunden habe ich vom Support ein entsprechendes BIOS mit einer aktuellen und funktionierenden TPM-Firmware bekommen.
Sprich, es scheint sich zu lohnen, den Support der Hersteller diesbezüglich zu kontaktieren.