AMD streicht AGESA: OpenSIL soll ab 2026 die neue UEFI-Firmware für Ryzen und Epyc werden
AMD soll beabsichtigen, seine aktuelle Firmware-Architektur AGESA ab 2026 durch die Open-Source-Firmware OpenSIL zu ersetzen. Die neue Implementierung soll dabei schrittweise für alle Plattformen in den Bereichen Desktop, Notebook, Server und Embedded ausgerollt werden.
Wie die auf Linux spezialisierte Website Phoronix zuerst berichten konnte, soll AMD beabsichtigen, seine aktuelle Firmware-Architektur ab 2026 mit einer vollständig neu entwickelten x86-Firmware zu ersetzen. Demnach soll die erst vor wenigen Wochen vorgestellte Open Source x86 Silicon Initialization Library ("OpenSIL") die bisher genutzte AMD Generic Encapsulated Software Architecture ("AGESA") dann vollständig ablösen und sowohl für Ryzen als auch Epyc genutzt werden.
Quelle: AMD
Open Source x86 Silicon Initialization Library ("OpenSIL")
OpenSIL soll AGESA ab 2026 ablösen
Auf dem OCP Regional Summit, der kürzlich in Prag stattfand, teilte AMD seine Pläne mit, seine AMD Generic Encapsulated Software Architecture ("AGESA") durch die neue Open-Source Silicon Initialization Library ("OpenSIL") zu ersetzen. Die neu geschaffene Firmware-Architektur soll nach einer mehrjährigen Entwicklungsphase schon ab dem Jahre 2026 für den produktiven Einsatz in den Bereichen Desktop, Notebook, Server und Embedded bereit sein und sowohl im Client- als auch Enterprise-Business eingesetzt werden. Ein erster Proof of Concept ("PoC") steht bereits bereit.
Eine neuere, offene Architektur, die potenziell eine geringere Angriffsfläche und eine scheinbar unbegrenzte Skalierbarkeit ermöglicht, ist jetzt als Proof-of-Concept in der Open-Source-Community zur Evaluierung verfügbar.
AMD, Open Source x86 Silicon Initialization Libraty ("OpenSIL")
Die dazugehörigen Bibliotheken sind von Grund auf neu in C17 geschrieben und sollen explizit als Open Source bereitstehen. Diese Bibliotheken sollen sich statisch in die System-Host-Firmware wie Coreboot und UEFI verlinken lassen.
OpenSIL ist ein Gemeinschaftsprojekt
Entwickelt wurde das Gemeinschaftsprojekt von AMD in Zusammenarbeit mit dem Firmware-Entwickler AMI ("American Megatrends") sowie den Coreboot-Spezialisten von 9Elements. Ebenfalls beteiligt waren die Server- und Rechenzentrumsbetreiber AWS, Datacom, Google und Meta sowie das Start-up-Unternehmen Oxide.
Quelle: AMD
Open Source x86 Silicon Initialization Library ("OpenSIL")
Wie AGESA ist auch OpenSIL unter anderem für die Initialisierungsprozesse verschiedener Subsysteme der Plattform verantwortlich, darunter Prozessorkerne, Chipsätze und Speicher. OpenSIL ist "leichtgewichtig, einfach, transparent und sicher und kann leicht skaliert werden", so AMD
Epyc 9004 ("Genoa") macht den Anfang
In der aktuellen Phase, dem Proof of Concept, ist OpenSIL ausschließlich mit den Server-Prozessoren der Serie Epyc 9004 ("Genoa") kompatibel und soll anschließend auch auf Epyc 9005 ("Turin") lauffähig sein. Ab 2026 soll die neue Firmware als Bestandteil des UEFI dann schrittweise die AGESA-Architektur ablösen.
Quelle: AMD
Open Source x86 Silicon Initialization Library ("OpenSIL")
Der ausführliche Bericht "Empowering The Industry with Open System Firmware" auf dem Community-Blog von AMD liefert viele weitere Hintergrundinformationen zu OpenSIL und der Implementierung von Coreboot.
Ihre Meinung ist gefragt!
Wie stehen Sie zu diesem Thema? Die PCGH-Redaktion freut sich über Ihre fundierte Meinung in den Kommentaren zu dieser Meldung. Um zu kommentieren, müssen Sie auf PCGH.de oder im Extreme-Forum eingeloggt sein. Sollten Sie noch keinen Account haben, könnten Sie sich hier unverbindlich registrieren.
Quelle: AMD via Phoronix
Wenn AMD wirklich die volle Kontrolle über die Firmware aus der Hand geben sollte, haben sie keine Möglichkeit mehr, Features auf diesem Wege zu sperren. OC-Lock für X3D via AGESA? Nicht möglich, wenn man sich seine eigene Alternative kompilieren kann. PCI-E-4.0-Code für X370/B350/X470/B450 verbieten? Nicht mehr, nachdem man ihn frei zur Verfügung gestellt hat. Ryzen-1000-Besitzer bei Mainboard-Defekt zum CPU-Neukauf zwingen? Nöp, jetzt können die Mainboard-Hersteller ganz offiziell alte Architekturen auf neuen Platinen unterstützen.
Genau deswegen bin ich aber mal gespannt, wie viel da tatsächlich freigegeben wird. Vertrauensbasis in der Cloud ist auch schwieriger, wenn signierte Firmware als solche kein Beweis mehr dafür ist, dass es sich um unmanipulierte Firmware vom CPU-Hersteller als einzigen Quellcode-Kenner handelt.
Und wenn es die Mainboardhersteller nicht können, dann ist es quasi nicht existent. Die Möglichkeit neue Features auf alte Platinen zu bringen gab es schon mal - Ich habe z.B. (Achtung Schleichwerbung) vor Jahren mal einen Guide geschrieben wie man eine NVME SSD unter Sandy Bridge bootfähig macht.
Firmware selbst kompilieren oder auch nur aufspielen ist kein Spaß, denn im Gegensatz zum modernen Übertakten kann man da relativ einfach teure Komponenten grillen.
Wie gesagt, ich freue mich trotzdem drauf, und es ist erfrischend so etwas im Zeitalter von verlötetem RAM und zugenagelten Bootloadern zu sehen. Ich glaube allerdings auch, dass es für 99.999% der Anwender keinerlei Unterschied machen wird.
Kompatibilitätsprobleme beim Spielen finden sich zu 100% auf Betriebssystem und Anwendungsseite, ein Linux kann auch heute schon einen AMD Prozessor genauso gut nutzen wie ein Windows (von TPM-Modulen, die proprietäre Firmware brauchen mal abgesehen, aber das wird sich vermutlich nicht ändern).
Sollte sich OpenSIL langfristig durchsetzen wird der Schritt den Betriebssystementwicklern ein wenig Arbeit abnehmen, weil sie sich nicht mehr mit den Details der Hardwareintialisierung verschiedener Hersteller beim Boot rumschlagen müssen.
Kurz: Idealerweise wird sich für den Anwender mittelfristig nichts ändern, im Guten wie im Schlechten.
Wenn AMD wirklich die volle Kontrolle über die Firmware aus der Hand geben sollte, haben sie keine Möglichkeit mehr, Features auf diesem Wege zu sperren. OC-Lock für X3D via AGESA? Nicht möglich, wenn man sich seine eigene Alternative kompilieren kann. PCI-E-4.0-Code für X370/B350/X470/B450 verbieten? Nicht mehr, nachdem man ihn frei zur Verfügung gestellt hat. Ryzen-1000-Besitzer bei Mainboard-Defekt zum CPU-Neukauf zwingen? Nöp, jetzt können die Mainboard-Hersteller ganz offiziell alte Architekturen auf neuen Platinen unterstützen.
Genau deswegen bin ich aber mal gespannt, wie viel da tatsächlich freigegeben wird. Vertrauensbasis in der Cloud ist auch schwieriger, wenn signierte Firmware als solche kein Beweis mehr dafür ist, dass es sich um unmanipulierte Firmware vom CPU-Hersteller als einzigen Quellcode-Kenner handelt.
Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...
Man sieht das übrigens jetzt auch wieder an den AI-Projekten. OpenAI ist eben nicht wirklich "open" und wird geradezu zwangsläufig von offenen Projekten verdrängt werden, wenn es sich nicht anpasst. Siehe:
[Ins Forum, um diesen Inhalt zu sehen]
Du hast immerhin den Schritt des Debugens dazwischen und die Lesbarkeit des Codes steht nochmal auf eiem ganz anderen Blatt....
Zudem bin ich (mal wieder) gespannt, wieviele die hier nach open source schreien, ihren Anteil am Projekt einbringen werden oder zumindest Fehlerberichte absetzen.
Es gibt gute Gründe, weshalb Verschlüsselungen und vieles andere open Source sind - wie z.B. PhysX (auch wenn Nvidia sich da doch mehr ein Deckmäntelchen umhängt... ) Oder auch AES (wie oben schon erwähnt) und andere Verschlüsselungsmethoden.
Du kannst so die zur Verfügung gestellten Softwareteile einfach in neue Produkte implementieren, ohne dir bei einzelnen Anbietern unnötig lange Approval Prozesse aufbürden zu lassen - oder wie GPU PhysX, dass Nvidia exklusiv war und deshalb einen einsamen Tod starb.
Ein anderes Beispiel ist Nvidias neue NTC Technologie... schöne Tech.. leider wird das Ding vor sich hinsterben... Immerhin braucht die Tech gleichgroße Texturen, um zu funktionieren.
Das wird aber nur passieren, wenn die Technologie frei für alle verfügbar ist.
Sonst macht sich niemand den Aufwand, die Texturen in gleich große Teile zu zerschnibbeln.
Ansonsten wird halt die Landschaft mit den großen Texturen darüber abgehandelt und der Rest halt nicht.
Außerdem dürfte die Technologie mit UE5 nicht mehr ganz so wichtig sein, da der Detailgrad nahtlos modifiziert wird.
Du hast immerhin den Schritt des Debugens dazwischen und die Lesbarkeit des Codes steht nochmal auf eiem ganz anderen Blatt....
Zudem bin ich (mal wieder) gespannt, wieviele die hier nach open source schreien, ihren Anteil am Projekt einbringen werden oder zumindest Fehlerberichte absetzen.