News AMD streicht AGESA: OpenSIL soll ab 2026 die neue UEFI-Firmware für Ryzen und Epyc werden

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu 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.

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: AMD streicht AGESA: OpenSIL soll ab 2026 die neue UEFI-Firmware für Ryzen und Epyc werden

 

[Ellina]

Klingt interesannt. Vor allem das AMD das Open Source macht und am ende die ganzen Linuxe profetieren.

Das zeigt dass man interesse hat denke mal in richtung gaming einen weiteren schritt zu machen der unabhängig von OS sein wird. Denke mal Agesa ist eher für Windows optimiert b.z.w profetiert an meisten davon.

Dafür müßte aber auch genau so wie windows tools da sein die zur überwachung sinnvoll verwendent werden kann.

 

[rum]

Find ich gut! Open Source & vermutlich mehr unterstütze Beriebssystem-Familien ist immer gut!

 

[peru3232]

2026 ist leider noch lange hin, aber toll, dass sich da was bewegt! Noch besser, dass da coreboot auch mit eingebunden ist - das kann gute Zeiten für open source, Linux und BSD einläuten

 

[Rollora]

2026 ist leider noch lange hin,

Hmm ich finde das eigentlich gar nicht so lange. Letztlich handelt es sich um eine weitreichende Veränderung in einem kritischen Bereich, der eigentlich noch Jahrelang getestet werden wird.
Wenn man bedenkt wie lange wir auf andere Dinge warten. Diverse Spiele etwa oder bis Intel den 2016 angesetzten 10nm Prozess tatsächlich in den Desktop brachte.
2026 sind 3 Jahre, das ist nicht weiter schlimm. Da will Intel angeblich bis dahin ja auch mehrere neue Prozesse usw usf bringen.

 

[Ellina]

2026 ist leider noch lange hin, aber toll, dass sich da was bewegt! Noch besser, dass da coreboot auch mit eingebunden ist - das kann gute Zeiten für open source, Linux und BSD einläuten

Die ankündigung ist alleine schon finde ich persönlich gesehen ne signal das amd mit den ganzen opensil wechsel eine starkes signal zeigt dass die gaming Unter linux nativ mehr optionen bringt und da abgezielt wird das es noch konfortabler wird und dass die ganzen linuxe damit abselut profetiert und dass muss man so sagen.

Am ende ist es halt lange aber wehr weis was in den nächsten 2 jahren noch passiert wir haben jetzt die hälfte von 2023 rum und deswegen sind die nächsten 6 monate auch nicht mehr so lange daher die 2 jahre.

am ende gibt es genügent änderungen dass die Gaming unter linux ne schub geben könnte und damit gerade fürs native gamen profetieren könnte wer weis was sich da noch alles in der richtung ändert vor allem bei den ganzen Publishern die ein sehen das linux nicht nur ne unter zwei stelliger OS % zahlen bei spieler:innen inne hat sondern eventuell mehr wird.

 

[Mephisto_xD]

Der Schritt ist natürlich gut, aber ich denke hier machen sich ein paar etwas zu große Hoffnungen auf die Auswirkungen auf der Anwenderseite.

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.

 

[Mironicus1337]

Und damit besonders anfällig für Hacker da der Code frei im Netz liegt.

Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...

 

[Ulathar]

Find ich interessant. Da wird sich Valve mit SteamOS und dem Steam Deck sicher auch bereits freuen. Plus dadurch, dass sich sicher eine entsprechende Community rund um die Software bilden wird könnte das perspektivisch auch zu besserer Software führen bzw. so wie es jetzt auch schon bei Linux passiert entsprechende Forks mit Tweaks und Erweiterungen für die experimentierfreudigeren geben.
Aber wie genau wird das 2026 dann laufen? Wirds dann für bestehende Boards einfach ein Update geben was das von AGESA umstellt oder setzt das wieder neue Boards und Co voraus?

 

[1xok]

Und damit besonders anfällig für Hacker da der Code frei im Netz liegt.

Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...

Weil Linux ja auch schon so unsicher ist ...

Security through obscurity war noch nie eine gute Idee.

 

[Mironicus1337]

Weil Linux ja auch schon so unsicher ist ...

Das Betriebssystem und der Kernel sind ja nicht die Ebene um die es geht.

Security through obscurity war noch nie eine gute Idee.

Wenn der Hersteller seine Hausaufgaben macht, dann schon.
So sehe ich das wie folgt.

Hey, OEMs, wir wissen, dass Sie unsere AGESA-Pakete hassen und der Mangel an Dokumentation macht es Ihnen wirklich schwer unsere Hardware in Ihre Systeme zu implementieren, also ist hier eine Lösung.

Wir werden Ihnen einige einfache vorkompilierte Dinge mit einer Reihe von Befehlen zur Verfügung stellen und Sie können einfach Ihre eigenen erstellen und selbst dokumentieren, wenn Sie schon dabei sind...

 

[Khabarak]

Find ich interessant. Da wird sich Valve mit SteamOS und dem Steam Deck sicher auch bereits freuen. Plus dadurch, dass sich sicher eine entsprechende Community rund um die Software bilden wird könnte das perspektivisch auch zu besserer Software führen bzw. so wie es jetzt auch schon bei Linux passiert entsprechende Forks mit Tweaks und Erweiterungen für die experimentierfreudigeren geben.
Aber wie genau wird das 2026 dann laufen? Wirds dann für bestehende Boards einfach ein Update geben was das von AGESA umstellt oder setzt das wieder neue Boards und Co voraus?

2026 wird es ne neue CPU Generation geben - eventuell erst 2027 für desktop - und damit dann neue Boards mitsamt AM6

 

[Ellina]

Und damit besonders anfällig für Hacker da der Code frei im Netz liegt.

Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...

Ist so wie bei allen sachen. Wurde bei anderen Freien Softwaren mehr angriffe und betrug duch gefüht. Statistisch gesehen warscheinlich nicht mehr als wo anders.

Dieser Persmismus.

Der Schritt ist natürlich gut, aber ich denke hier machen sich ein paar etwas zu große Hoffnungen auf die Auswirkungen auf der Anwenderseite.

Nö aber dessen das es kommen soll und das es in eine andere richtung geht ist alleine schon ne gute sache. Mehr oder weniger wird sich zeigen wie es wird.

Wenn der Hersteller seine Hausaufgaben macht, dann schon.
So sehe ich das wie folgt.

Wenn sie es machen abe dein erster post sugariert das tür und tor für alles geöffnet ist. Einfach drauf an kommen lassen bisschen zeit ist ja noch und dann kommen bestimmt noch mehr informationen.

2026 wird es ne neue CPU Generation geben - eventuell erst 2027 für desktop - und damit dann neue Boards mitsamt AM6

mal davon ab, wissen wir nicht was es dann gibt. die nächste mögliche generation ist die core 14the 2024 und dann ist relativ sicher das da refrash kommt also 2025 und dann ist ja sicher das amd bis 2025 supportet am5. Also da fließt genügent paste übern heatspreader runter (wort witz) und bis dahin ist viel passiert wer weis wo wir dann stehen.

Das ist oder wäre spekulation.

 

[AleisterHH]

Und damit besonders anfällig für Hacker da der Code frei im Netz liegt.

Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...

Weil Linux ja auch schon so unsicher ist ...

Security through obscurity war noch nie eine gute Idee.

Don't feed the troll...

Aber zum Thema:
Verstehe ich das richtig, das openSIL Hand in Hand mit coreboot kommt?

 

[Flatline00]

Finde ich sehr interessant, coreboot fand ich vom Prinzip her interessant, schien mir aber bisher zuviel zu opfern was oc uv etc angeht.
Damit könnte dann coreboot auch eine valide alternative sein ohne zuviel zu opfern.

Was die Sicherheit von open source betrifft, btw. AES ist open source

 

[ZeroZerp]

Don't feed the troll...

Weil es ja anderweitig besser ist?
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.

 

[Khabarak]

Weil es ja anderweitig besser ist?
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.

Sorry, aber das ist eine sehr eingegrenzte Sichtweise.
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.

 

[1xok]

Zudem bin ich (mal wieder) gespannt, wieviele die hier nach open source schreien, ihren Anteil am Projekt einbringen werden oder zumindest Fehlerberichte absetzen.

Die meisten Änderungen kommen von den beteiligten Unternehmen selbst. Open Source ist ein in der Industrie inzwischen weit verbreitetes Konzept. Ein Kulturkampf wird darum schon lange nicht mehr geführt. Der aktuell Hauptbeitragende zum Linux Kernel ist Oracle. Die Unternehmen machen das nicht um der Konkurrenz Firmengeheimnisse zu schenken oder gar Hackern das Leben zu erleichtern. Es ist einfach eine Tatsache, dass das Internet die Art und Weise wie Software entwickelt wird radikal verändert hat. Open Source und das Internet hängen dabei eng zusammen. Nur durch Open Source und offene Standards (RFCs) konnte sich das Internet so schnell entwickeln. Nur dadurch entwickelt es sich weiter.

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:

Google-Entwickler: Open-Source-KI wird Google und OpenAI den Rang ablaufen

In einem geleakten Dokument fordert ein leitender Entwickler Google zur Zusammenarbeit mit den sich rasant entwickelnden Open-Source-KI-Projekten auf.

www.heise.de

 

[PCGH_Torsten]

Der Schritt ist natürlich gut, aber ich denke hier machen sich ein paar etwas zu große Hoffnungen auf die Auswirkungen auf der Anwenderseite.

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.

Die Veröffentlichung von Firmware-Code nach ähnlichen Lizenzmodellen, unter denen es auch Betriebssystem-Code gibt, hat zwar null Einfluss auf die Interaktion zwischen beiden, die ohnehin definiert ist. Aber in einem anderen Bereich könnten Anwender einen gewaltigen Unterschied spüren:
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 damit besonders anfällig für Hacker da der Code frei im Netz liegt.

Einfallstor für Spionage- und Schadsoftware im privaten und Serverumfeld. Super Idee...

Wenn Hacker und Spione auf deinem Rechner ein selbst kompiliertes UEFI installieren konnten, dann gab es vermutlich vorher schon ein Einfallstor.

 

[Mephisto_xD]

Die Veröffentlichung von Firmware-Code nach ähnlichen Lizenzmodellen, unter denen es auch Betriebssystem-Code gibt, hat zwar null Einfluss auf die Interaktion zwischen beiden, die ohnehin definiert ist. Aber in einem anderen Bereich könnten Anwender einen gewaltigen Unterschied spüren:
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.

Bin vielleicht etwas pessimistisch, aber ich denke mal da wird es genug Möglichkeiten seitens AMD geben ungewünschte Features zu unterbinden - bei den Mainboardherstellern reicht da vermutlich eine Vertragsklausel, aber auch technisch wenn notwendig.

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.