Secure Boot: ja oder nein?

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 signierten Bootloader beschränkt: Secure Boot ermöglicht den gesicherten Beginn 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&aumlä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 sie in Kürze die Möglichkeit haben, 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 und Ablauf von Secure Boot-Zertifikaten. 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. Die 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&uuml 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&aumlä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 will,
• eine Standarddistribution wie Fedora, Ubuntu oder openSUSE nutzt.

Nein bzw. optional, wenn du:

• ein Entwickler bist, der seinen eigenen Kernel oder Bootloader testet,
• ältere Hardware nutzt, die Secure Boot nicht gut unterstützt,
• maximale Kontrolle über Ihr System will.

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:

• Lassen Sie 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 sie nicht wissen wollen, 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 sie 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. Hat sie Secure Boot eingeschaltet oder nicht und warum? Schreiben Sie es bitte in die Kommentare. Konntet ihr nach dem 11. September nicht mehr booten, weil das Zertifikat bei Ihnen 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/