Auf Mastodon ansehen
Ich habe einen alten Lappen aus der Schublade gezogen: Secure Boot. Das Thema ist so alt, wie der Tag, an dem Microsoft diesen «Sicherheitsmechanismus» erfunden hat. Doch was ist Secure Boot überhaupt? Die Wikipedia schreibt:
Mit der Einführung von Windows 8 im Jahr 2012 wurde das UEFI in der Version 2.3.1 mit einem „Secure Boot“-Mechanismus verstärkt eingeführt, der das Booten auf vorher signierte Bootloader beschränkt: Secure Boot ermöglicht den gesicherten Anfang einer unterbrechungsfreien „Vertrauens-Kette“ von der Hardware-Firmware bis zur Benutzeranwendung. Das erhöht die Sicherheit beim Systemstart u. a. weil es Schadsoftware, der die passenden Signaturen fehlen, im Grundsatz nicht mehr möglich ist, in den Boot-Prozess einzugreifen, es verhindert jedoch nicht, dass jedes Kettenglied auch „nicht-vertrauenswürdige“ Software nachladen kann.
Die Idee zu diesem Artikel kam mir, als ich diesen Beitrag auf Techrights gelesen habe (übersetzt):
Wir möchten daran erinnern, dass UEFI „9/11” im September ausläuft. UEFI war nie notwendig. Es wurde als „Lösungsansatz” entwickelt. Es ist eine Lösung auf der Suche nach einem tatsächlichen Problem. Wenn ihr in Kürze die Möglichkeit habt, das Boot-Menü aufzurufen (vielleicht bei einem Neustart), deaktiviert unbedingt „Secure Boot”. Diese Option hätte von vornherein nie aktiviert sein dürfen. Geht kein Risiko ein. Viele PCs schaffen es nicht, zu einem anderen Zertifikat zu wechseln.
Letztgenannter Auszug bezieht sich auf einen Artikel von Jake Edge vom Juli 2025 mit dem Titel: Linux and Secure Boot certificate expiration. Da dieser Artikel ziemlich lang ist, erlaube ich mir, euch eine übersetzte Zusammenfassung zu präsentieren (falls ihr nicht das Original lesen möchtet oder könnt). Die Zusammenfassung und Übersetzung habe ich mit Microsoft-Copilot erstellt:
🔐 Secure Boot und das Microsoft-Zertifikatproblem
Viele Linux-Systeme, die Secure Boot aktiviert haben, verlassen sich auf ein Microsoft-Zertifikat von 2011, das am 11. September 2025 abgelaufen ist. Dieses Zertifikat wurde verwendet, um den Shim-Bootloader zu signieren, der notwendig ist, um Linux mit Secure Boot zu starten.
🧩 Die Herausforderung:
Nach Ablauf des Zertifikats wird Microsoft keine neuen Shims mehr mit dem alten Schlüssel signieren. Ein neuer Schlüssel von 2023 existiert, aber: Er ist nicht auf allen Systemen installiert. Die Installation erfordert oft ein Firmware-Update vom Hardware-Hersteller, das möglicherweise nicht bereitgestellt wird.
🛠️ Mögliche Lösungen:
LVFS (Linux Vendor Firmware Service) und fwupd können helfen, Firmware-Updates zu verteilen. KEK-Updates (Key Exchange Key) sind eine Möglichkeit, neue Schlüssel in die Firmware-Datenbank zu bringen. Erfolgsquote liegt bei ~98–99 %, aber Millionen Systeme bedeuten trotzdem viele potenzielle Fehler. Probleme wie „failed to write efivarfs“ können auftreten, oft hilft ein BIOS-Reset.
⚠️ Risiken und Unsicherheiten:
Einige Hersteller haben ihre privaten Plattformschlüssel verloren, was schwerwiegende Sicherheitsprobleme verursacht. Es ist unklar, ob alle Firmware-Versionen das Ablaufdatum des alten Schlüssels tatsächlich durchsetzen. Ein Workaround wäre, alte Shims weiter zu verwenden, was aber Sicherheitslücken offenlässt.
📌 Fazit:
Die Linux-Community arbeitet aktiv an Lösungen, aber: Benutzer und Distributionen müssen wachsam sein. Firmware-Updates sind entscheidend, aber nicht garantiert. In manchen Fällen bleibt nur die Option, Secure Boot zu deaktivieren, um neue Installationen zu ermöglichen.
Nun stellt sich die Frage, ob Secure Boot für Linux-Anwender:innen notwendig ist:
Ja, wenn du:
- ein System in einer sicherheitskritischen Umgebung betreibst,
- möglichst hohe Integrität beim Bootprozess willst,
- eine Standarddistribution wie Fedora, Ubuntu oder openSUSE nutzt.
Nein bzw. optional, wenn du:
- ein Entwickler bist, der eigene Kernel oder Bootloader testet,
- ältere Hardware nutzt, die Secure Boot nicht gut unterstützt,
- maximale Kontrolle über dein System willst.
Secure Boot ist nicht zwingend notwendig für alle Linux-Anwender, aber nützlich für bestimmte Szenarien. Viele erfahrene Nutzer deaktivieren es bewusst, um mehr Flexibilität zu haben – insbesondere bei Dual-Boot-Systemen oder Custom-Setups.
Hier noch ein paar zufällige Äusserungen aus dem Internet:
- Lass diesen unsinnigen SecureBoot-Mist einfach deaktiviert. Manjaro/Arch unterstützt das offiziell nicht. Nur Ubuntu.
- Mach den Quatsch einfach aus. Der Sicherheitsgewinn ist auf Privat-Computern kaum vorhanden. Böse Zungen würden behaupten, dass sich MS den Quatsch nur ausgedacht hat, um ihr Windows-Monopol auf PCs zu zementieren.
- Secure Boot bootet Betriebssysteme mit Lücken per Default, daher ist der Sicherheitsgewinn marginal bis nicht vorhanden.
Falls ihr nicht wisst, ob Secure Boot auf eurem Rechner ein- oder ausgeschaltet ist, könnt ihr das prüfen, ohne beim Booten ins BIOS/EFI zu schalten. Dafür gibt es zwei Befehle, die ihr im Terminal ausführen könnt:
bootctl
Failed to read "/boot/efi/EFI/systemd": Keine Berechtigung
Failed to open '/boot/efi//loader/loader.conf': Keine Berechtigung
System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled (setup)
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported
Oder:
mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode
Falls das eine oder andere bei euch nicht läuft, wisst ihr, wie man diese Tools installiert, nämlich wie immer. Bootctl sollte standardmässig vorhanden sein, mokutil nicht.
Fazit
Das Fazit überlasse ich euch. Habt ihr Secure Boot eingeschaltet oder nicht und warum? Schreibt es bitte in die Kommentare. Konntet ihr nach dem 11. September nicht mehr booten, weil das Zertifikat bei euch abgelaufen ist? Seht ihr Vorteile oder Nachteile von Secure Boot?
Titelbild: Von https://www.adrenaline.com.br via DALL-E generiert
Quellen:
https://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot
https://en.wikipedia.org/wiki/UEFI#Secure_Boot_2
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
https://lwn.net/Articles/1029767/
https://www.computerbase.de/forum/threads/manjaro-und-secure-boot.2210034/
Heyho,
deaktiviert, da ich hierunter falle: "ältere Hardware nutzt, die Secure Boot nicht gut unterstützt,"
Bei neuerer Hardware würde ich es ggf. aktivieren, wäre mir da aber auch nicht so richtig sicher.
Grüße Xavin
Hab seit kurzen kein windows km einsatz, darum sehe ich keinen nutzen für uefi. Hab am we einmal linuxmint und manjaro installieren wollen. Hatte mächtige probleme mit grub. Es gibt keine option, das man linuxe dual laufen lässt. Aber ich werde nun uefi abschalten und schaun was passiert. Vieloeicht kommt ja ein clown zum vorschein lol
"Hatte mächtige probleme mit grub. Es gibt keine option, das man linuxe dual laufen lässt." Wenn ich das richtig in Erinnerung habe, wurde der os-prober aus irgendwelchen Gründen deaktiviert. Vielleicht liegt es daran?
Nachtrag, hab mal im Bios nachgeschaut und musste verblüfft festellen, das die Zertifikate deaktivert wurden. Scheintbar hat der Hersteller von meinen PC, hier mal mitgedacht.
SecureBoot an sich ist nicht das Problem und ja es könnte (genau wie der Rest des UEFI) "schöner" implementiert sein. Allein das so etwas wie SBAT nachträglich hinzugefügt werden musste weil die DBX-Blacklist zu gross wurde ist alles andere als schön. Das Problem sind aber die Zertifikate die standardmässig mit einem Computer ausgeliefert werden. Denn diese Zertifikate zementieren das Monopol von Microsoft und ihre Kontrolle über die Computer die weltweit verkauft werden.
Meine Idee wäre das die Firmware von jedem Computer beim ersten hochfahren einen "Einrichtungsassistenten" anzeigt der es dem Besitzer des Gerätes auf einfache Weise, also ohne umfangreiche Kenntnisse von der Materie, ermöglicht selber zu entscheiden welchen Zertifikaten von welchen Organisationen für die Vertrauenswürdigkeit der zu startenden Software verwendet werden sollen.
Und wenn dann die meisten sagen, das sie Microsoft vertrauen dann ist es vielleicht ein nicht ganz so intelligente aber wenigstens eine selbstbestimmte Entscheidung.
Secure Boot habe ich bisher auf jeder Kiste von Anfang an deaktiviert. Der Bedarf ist bei mir auch gar nicht gegeben, Schutzmöglichkeiten gibt es anders auch. Die Idee mag ja gut sein, aber da würde ich wohl auch auf die Schnauze fliegen, weil ich oft tagelang kein System neustarte. Ich gehe auch nicht davon aus, dass zeitnah eine Meldung beim Booten vorbeihuscht, die auf ein bald auslaufendes Zertifikat hinweisen würde…
Wenn Microsoft uns schon nicht Windows aufzwingen kann, dann wenigstens diesen Müll?
es iss ja nicht nur Microsoft, das sind auch die ganzen Firmen, die da auch mit pielen und die ganzen Programmierer, die den scheiss übernehmen - bei linux- drängen uns dann indirekt auf..
nur....... wir können auch lagency boot nehmen..., aber, es gibt immer weniger solche Mainboards die eine Lagency-möglichkeit des boot uns servieren..
liebe Grüße Blacky
Die Vendor Keys kann man entfernen und durch eigene ersetzen, dann hat man auch keine Probleme mit Microsoft-Zertifikaten!
Mein Ubuntu (25.04) sagt mir, das bootctl im Paket systemd-boot zu finden wäre, aktuell ist es auf dem Rechner nicht installiert. Ubuntu bootet noch viel mit grub.
Es gab ja schon in früheren Zeiten Bootsektor-Viren, ganz aus der Welt ist das Konzept nicht. Der Aufwand immer Keys einzuspielen kann hoch sein, z.T versucht man das ja zu aktulisieren. Den Grad einer Verdongelung eines Systems kann man sicherlich sehr weit treiben, man denke nur Apple Smartphones.
Wie sieht das Verhältnis aus, wenn man kein SecureBoot verwendet, aber eine verschlüsselte Festplatte? Ist das dann sicher, oder eher nicht?
Und hier die Berater-Antwort: „Das kommt darauf an“. Festplattenverschlüsselung ist eine gute Maßnahme, v. a. gegen den physischen Zugang zu Deinen Daten. Aber sie ist nur ein Glied in der oben angesprochenen Vertrauenskette. Wenn Du Dir bereits beim Bootvorgang eine Malware lädtst, kann die in Ruhe warten, bis Du Deine Platte aufgeschlossen hast.
Persönliche Meinung: Für mich ist im privaten Betrieb der Nutzen von Secure Boot nicht erkennbar, daher bleibt es bei mir aus.
Und hier die Berater-Antwort: „Das kommt darauf an“. Festplattenverschlüsselung ist eine gute Maßnahme, v. a. gegen den physischen Zugang zu Deinen Daten. Aber sie ist nur ein Glied in der oben angesprochenen Vertrauenskette. Wenn Du Dir bereits beim Bootvorgang eine Malware lädtst, kann die in Ruhe warten, bis Du Deine Platte aufgeschlossen hast.
Persönliche Meinung: Für mich ist im privaten Betrieb der Nutzen von Secure Boot nicht erkennbar, daher bleibt es bei mir aus.
Ihr habt vergessen eine die Situation Laptop zu betrachten. Hier finde ich Secure-Boot ebenfalls angebracht. Hier würde mich allerdings noch interessieren, wie sich Secure-boot mit Laufwerksverschlüsselung verträgt und ggf. die Sicherheit beeinflusst.
Mama will übrigens kein Laufwerkspasswort eingeben müssen. Der Fingerabdruck oder ein Fido Key wäre besser. Am besten noch wäre es, wenn Linux trotz allem bis zum User-Login booten könnte. Es muss einfach nutzbar sein. Da es das aktuell nicht ist, hat Mama einen Laptop ohne Festplattenverschlüsselung.
Auf meinen Privatrechnern ist Secureboot aus. Ich nutze gerne mehrere Betriebssysteme, rotiere die auch mal gerne und meine Hardware ist auch nicht die jüngste. Den potentiell möglichen Sicherheitsverlust nehme ich gerne in Kauf. Ich hätte auch noch von keiner Malware gehört, welche sich durch Secureboot abhalten liese sich zu installieren. Das meiste was an Malware reinkommt wird vom User ausgeführt und kann im Userkontext eh schon genügend Schaden anrichten.
Anders sieht es bei den Firmenrechnern aus. Da aktiviere ich Secureboot. Da läuft nur Windows, nur die aktuellste Version, nur auf aktuellen Geräten und dort ist potentiell auch Industriespionage möglich. Da macht Secureboot auch Sinn.
Ich finde Secureboot nichts per se schlechtes. Aber der Sicherheitsgewinn ist im privaten Rahmen überschaubar und man kann sich damit auch diverse Probleme einhandeln.
Genau meine Meinung.
SecureBoot ist bei mir deaktiviert. Auf dem Desktop-PC habe ich gar eine BIOS-Installation mit MBR (CSM) statt EFI konfiguriert, die gar kein SecureBoot kennt. Darin läuft Win 10 noch im Dual-Boot, wenn es auch sehr selten gebootet wird. TPM ist ebenfalls abgeschaltet. MicroSoft kann mich 'mal. Deren 'Errungenschaften' werden nur als sicher gebrandet und dienen eher anderen Zielen, was ich hier nicht ausführen möchte.
@gerriet Ich hatte auf dem Notebook lange Zeit Manjaro und MX-Linux im Dual-Boot mit grub laufen. BIOS statt EFI - geht aber beides. Tatsächlich hatte ich seinerzeit Probleme bei der Installation, die aber eher EFI (bei einer MBR-Installation) betraf. Soweit ich erinnere habe ich die zweite Linux-Installation ohne grub installiert. Dazu muß dann aber os-prober (grub) aktiviert sein, da dann das erste Linux einen Eintrag zum zweiten Linux im grub-Boot-Menü erhält. In einer EFI-Installation sollte das aber einfacher sein, da die Sprungadressen dann im EFI liegen und beide Systeme einen grub haben können.
Die Free Software Foundation nennt es richtigerweise "Restricted Boot". Wenn man sich anschaut, wer dahintersteckt, vor allem Microsoft, dann wundert einen nichts mehr. Denen wäre es natürlich lieber, wenn die Leute Windows nutzen würden. Da kann man anderen schon mal, natürlich nur aus Versehen, ein paar kleine Steine in den Weg legen.
Privates System ist es deaktiviert, auf Grund von maximaler Kontrolle und höheren Gründen (wie Dev, custom kernel etc.)
Produktive Systeme haben es aktiv (inkl. dualboot). Produktive Systeme deren Key abgelaufen ist und derzeit kein Update erhalten, bekommen einen custom key geladen womit shim validiert wurde.
(versteht sich von selbst, dass der key selbst nicht auf dem System liegt um Kompromittierungen zu vermeiden).
secure boot macht abhängig von microsoft, weil nur sie den boot-loader zertifizieren. einen wirklichen mehrwert oder schutz vor was? hat es nie gegeben. ein künstliches problem, das wir nie gebraucht hätten.
Und wieder ein Beispiel von KI-Diebstahl im Titelbild.
Wie gesagt, ich werde es immer und immer wieder erwähnen bis ihr selbst offiziell sagt "jo wir unterstützen Diebstahl, akzeptiere es" oder ihr eure Praxis anpasst. Bei ersterem werde ich dann schlussendlich gehen.
Warum KI? Sichtbare Halluzinationen welche absolut typisch sind bei generative KI sind.
Ich empfinde es als absolut verwerflich, wie man Diebstahl an Künstlern derartig schamlos unterstützt. "Ist ja kostenlos" ist keinerlei Ausrede. Es ist nachweislich Diebstahl und es gibt nicht umsonst Klagen.
Der kleine Künstler kann das nicht. Sorry, aber ihr habt eine Verantwortung den Lesern gegenüber und solltet es als IT-Blatt wesentlich besser wissen.
Vielen Dank für den Hinweis. Das verwendete Titelbild wurde (wie angegeben) mit einem KI-Tool generiert. Es handelt sich um ein Trivialbild in Drittverwendung. Uns ist bewusst, dass dies kritisch gesehen wird, weshalb wir überwiegend eigenproduzierte oder exklusive Bilder verwenden.
Tatsächlich habe ich SecureBoot aktiv. Der Hardwarehersteller erlaubt das Austauschen aller Keys, vom PK bis zu den db[x]-Sammlungen. Insofern habe ich tatsächlich keine Probleme. Ob die Expiry-Dates der Kette durchgesetzt werden, müsste ich prüfen.
Eine interessante Erkenntnis ist, dass die Windows File Protection den neu signierten Windows Bootloader als beschädigt betrachtet und regelmäßig durch die nur von MS signierte Variante ersetzt, die bei mir naturgemäß nicht startet.
Anstatt erstmal zu prüfen, ob die eigene Signatur am Bootloader noch gültig ist. Danke Microsoft, damit wäre dann beantwortet, für wen SecureBoot tatsächlich eingeführt wurde. Oder die Frage nach der Intelligenz Eurer Produktentwickler. Und ja, das war vor ChatGPT und Vibecoding.
Sicherheitsgewinn für den privaten PC = NULL. Eigentlich nur sinnvoll bei Firmen-PCs und dort insbesondere für Laptops die auf Reisen gehen müssen. Aber es ist ein Unding das ausgerechnet eine Firma wie Microsoft, wegen den Zertifikaten, die Funktionsweise bestimmt und andere Betriebssystemhersteller damit in der Hand hat. Und sie haben es in der Vergangenheit sogar schon selbst zerlegt, siehe https://winfuture.de/news,93558.html und https://www.heise.de/news/Kardinalfehler-Microsoft-setzt-aus-Versehen-Secure-Boot-schachmatt-3291946.html (Das Foto hier ist Klasse! :-D)
Bei den SSL Zertifikaten hat es mit "Let's Encrypt" ebenso eine gewisse Zeit gedauert bis es endlich eine halbwegs vernünftige Lösung gab. Und eine offene Lösung braucht es eben auch in so einem wichtigen Bereich wie dem Booten von Betriebssystemen. Zum Glück gibt es einige alternative und zukunftsweisende Ansätze: https://canoeboot.org/ und https://www.coreboot.org/ und https://libreboot.org/ und https://www.tianocore.org/
> Bootctl sollte standardmässig vorhanden sein, mokutil nicht.
Bootctl gehört zu systemd-boot und ist also auf Systemen, die z.B. GRUB verwenden (wie bspw. Debian und Ubuntu es in der Regel tun), standardmäßig nicht vorhanden.
Ganz ehrlich. Ich beschäftige mich ja mit einigen Dingen, aber alles kann ich nun auch nicht.
Ich habe vor Jahren einen neuen Rechner gekauft und angefangen über EFI und Secure Boot zu lesen. Das war ermüdend. Mit dem Hintergedanken, wenn es nicht funktionieren sollte, könne ich immer noch den langweiligen Kram lesen, habe ich in einer Pause einfach Ubuntu MATE 21.10 verschlüsselt installiert und es läuft bis heute – natürlich halbjährlich auf die nächste STS gehoben.
Eben nachgeschaut: Secure Boot war voreingestellt und ist aktiv. Da es noch läuft, sehe ich vorerst keinen Handlungsbedarf. Aber gut zu wissen, dass da der Wurm drin stecken könnte. Ich harre auf den nächsten Kernel. :D
Eurer Artikel ist bei aktivierten Mozilla VPN mit Datenschutzfunktionen nicht erreichbar. Nutze Firefox Klar.
War im Sommer schon mal so.
Bei einem Stück Windows Rechner an, bei meinen bevorzugten Linux Rechner Secure Boot nicht aktiv, weil ältere Hardware und meine bevorzugte Distro mit Secure Boot fremdelt. Ich müßte erstmal eine Suchmaschine befragen ob meine Kisten noch ein neues Update damit Secure Boot reibungslos läuft. Ich sehe das Risiko aber vertretbar, jedenfalls für meinen Anwendungsfall. Für meine nächsten Rechner wünsche ich mir eine Lösung die eine einfache Nutzung von Secure Boot ohne Microsoft möglich ist. Vertrauen muss ich eh einer Stelle bei dem Thema Secure Boot.
efi, seit es efi oder UEFI gibt war das alleine von Microsoft durchgesetzt und allen Kommerziellen, die da nachher profitiren kööönten, hauptsache erstmal einbauen.. "Zur Sicherheit" natürlich erhöht es den Absatz von Hardware, weil dann Kommerzielle Einrichtungen wieder was verdienen, aber es wurde verschwiegen und unterdrückt, daß das Private gar nicht brauchen, wurde aber trotzdem durchgedrückt, auch das TPM, für was der Schbeep daß man per TPM jedem Gerät eine ID verpassen kann.. und natürlich gleich mal für Win10 Verwenden, daß die Absatzzahlen wieder passen und auch bei Win11, bei Win11 wird jetzt drauf geachtet, daß jeder benutzer in die Cloud geht, damit man da dann auch noch rumschnüffeln kann, war aber vorraus zu sehen, falls jemand sich an den Großen Prozess gegen Microsoft erinnert, bei dem ab dem zeit punkt Microsoft verpflichtet wurde, mit den Staatlichen Einrichtungen zusammen zu arbeiten ... unndd dann gibts noch div. Gesetze in den Staaten die dann voraussetzen, daß die div. Einrichtungen jederzeit nachverfolgen können müssen.. siehe Die Informationen von Snowden..
Also kurtz und schmerzlos, Wer brauch UEFI, die Privaten auf jeden Fall nicht Wer braucht TMP, kein Privater und nur Leute, die eingefangen werden sollen von Win10/11 wo TPM vorrausgesetzt wird.. Aber kein Linuxer .. nur die, die sich einlullen lassen und regelmäßig ARD und ZDF schauen..
Beim Linuxer reicht ein gut eingerichtetes 32Bit System, das ordendlich rennt, aber da Linux modern sein mächte und es anscheinend "alter unwichtiger scheiss" gib, wurde 32Bit abgeschnitten mit div. begründungen, anstatt, die 32Bit einfach ab zu hängen und Ihre eigene Community darum bilden zu lassen.. So hätten sich weitere Communitys bilden können.. die immer noch die 32Bit bez. x86 Hardware weiter betrieben werden können..
Aber man schaut ja nicht auf den Boden, beim nächsten Schritt, der sich Fortschritt nennt, alles was nicht wichtig erscheint, juckt nich und wird einfach verworfen.. aber das dann.. zu letzt.. auf den eigenen Privaten Boden, der dann Korrupt mit gezogen wird, weil nur die nicht das volle wissen haben, bezahlen auch.. weil sie es nicht besser wissen.. Also, viel Spaß beim nächsten loch, unter einem, wo man nur hoffen kann, daß das einem nicht alle Knochen bricht.. Tja, die Tatsachen des lebens ist zu guter letzt verdammt hart..
liebe Grüße Blacky
Hallo Blacky, ich würde gerne meinen Senf zu deinem Kommentar dazugeben. Ich bin nämlich der Ansicht, das UEFI auf für Privatleute enorme Vorteile hat.
Das sind für mich Gründe UEFI jederzeit BIOS vorzuziehen und ich setzte es überall ein, wo ich nur kann
Mittlerweile gibt es einige Anbieter, die Rechner mit Coreboot anbieten (System76, Purism, Nitrokey, Nova Custom, Star Labs). Dann hat man keine Probleme mehr mit Microsoft-Zertifikaten und kann die Vorteile von UEFI nutzen. Oder Coreboot/Libreboot selber flashen!
Ich habe Secure Boot aktiviert weil es eine Herausforderung war. Ich wollte es unter Linux hinbekommen und habe deshalb die Vendor Keys entfernt und durch eigene ersetzt. Dadurch habe ich auch keine Probleme mit den auslaufenden Microsoft-Zertifikaten. Bei der Gelegenheit habe ich auch gleich Grub in Rente geschickt, mein signiertes Unified Kernel Image wird direkt vom UEFI geladen.
Wow! Würdest du bitte darüber einen Artikel schreiben? Ich bin daran interessiert. Ich liebäugel seit einer Weile, den nächsten Rechner mit coreboot zu kaufen.