August

Bisher war Secure Boot kein Thema für mich. Sowohl Gentoo Linux als auch Windows 11 lassen sich im Dual Boot Setup mit dem Bootloader GRUB problemlos bei deaktiviertem Secure Boot starten.

Windows 11 verwende ich grundsätzlich nur für einige wenige Computerspiele, die nicht unter Linux funktionieren. Hauptursache sind meistens die Anti-Cheat-Komponenten, welche die Linux-Kompatibilität verhindern. Nun haben die ersten Spielestudios im Kampf gegen Cheater angekündigt, dass sie zukünftig ein aktiviertes Secure Boot für ihre Spiele voraussetzen werden. Und so wurde dieses Thema plötzlich für mich relevant.

Die Problematik

Secure Boot soll die Systemsicherheit erhöhen, indem nur kryptographisch signierte Programmteile vom Bios bzw. UEFI geladen werden. Und das durchgehend. In meinem Fall muss eine Kette von mindestens 3 Teilen berücksichtigt und signiert werden:

1. Der Kernel im Pre Boot Authorization System von SEDUTIL zum entsperren der per TCG OPAL Hardwareverschlüsselung gesperrten NVME-Speichermedien
2. Der Bootloader GRUB zur Auswahl des Betriebssystems
3. Der Kernel vom eigentlichen Gentoo Linux System bzw. vom Windows System

1. Vorbereitung im BIOS

Im BIOS bleibt Secure Boot zunächst deaktiviert. Hier beim ASUS Bios/UEFI ist dazu die Option "OS Type" auf den Wert "Other OS" gesetzt.

Allerdings muss Secure Boot in den Setup Modus versetzt werden, damit SBCTL (siehe Schritt 2) die Schlüssel installieren kann. Hier im ASUS Bios/UEFI setzt man dazu die Option "Secure Boot Mode" auf "Custom" und führt anschließend im Untermenü "Key Management" die Operation "Clear Secure Boot Keys" aus.

2. Vorbereitungen in Linux

Nachdem die Vorbereitungen im Bios abgeschlossen sind, kann das Linux System mit dem Tool SBCTL für Secure Boot vorbereitet werden. Das geht mit folgenden Befehlen:

Weitere Informationen zu diesem Vorgehen siehe: Gentoo Wiki: sbctl

3. Installieren und signieren von GRUB für Secure Boot

Damit GRUB bei aktiviertem Secure Boot korrekt booten kann, muss es auf eine bestimmte Art und Weise installiert und anschließend signiert werden. Das Signieren eines bereits vorhanden GRUB EFI Images ist ggf. nicht ausreichend, da ein dynamisches Nachladen von nicht signierten Modulen oder Fonts durch GRUB zu dem Fehler "error: prohibited by secure boot policy" führen kann (siehe dazu auch: EndeavourOS Forum: GRUB & Secure Boot).

Die Installation von GRUB kann wie folgt durchgeführt werden:

Zusätzlich sollte ggf. geprüft werden, ob das neue GRUB-Image an allen magischen Orten installiert ist, siehe letzter Punkt in meinem Artikel zur Einrichtung von SEDUTIL.

Anschließend müssen alle GRUB-Images (ggf. mehrere, falls an verschiedenen magischen Orten abgelegt) signiert werden, z.B. wie folgt:

4. Signieren der Gentoo Linux Kernel für Secure Boot

Auch die verwendeten Kernel des Gentoo Systems müssen signiert werden, z.B. wie folgt:

Daran muss auch nach jeder neuen Kernelinstallation gedacht werden. Ggf. ist dass im Installationsscript der Distributionskernel schon enthalten oder kann per USE-Flag aktiviert werden. Ich selbst benuzte allerdings noch das Tool GENKERNEL für die manuelle Kernelerstellung.

5. Signieren und installieren des Kernels im Pre Boot Authorization System von SEDUTIL für Secure Boot

Nun wird es etwas komplizierter: Wenn man wie ich ein Pre Boot Authorization System im Shadow MBR eines per TCG OPAL verschlüsselten NVME-Laufwerkes installiert hat, muss natürlich auch der Kernel dieses Systems signiert werden. Mit Hinweisen aus dem Fehlerbericht 259: [HowTo] SecureBoot support konnte ich jedoch eine Lösung finden.

Wichtig ist, dass hier als Ausgangslage das gleiche RESCUE-Image verwendet wird, welches auch bei der Ersteinrichtung der Pre Boot Authorization (PBA) System verwendet wurde, da es sonst zu Inkompatibilitäten kommen kann, siehe dazu auch Anmerkung weiter unten. Ich hatte für meine Systeme die Version RESCUE64-1.15.1-44-ge29fbb1.img.gz aus dem Repositoy von ChubbyAnt genutzt. Das Vorgehen sollte für alternative Rescue-Images von SEDUTIL identisch sein.

Zunächst muss das RESCUE-Image eingebunden werden, um Zugriff auf das vorkonfekionierte PBA-Image zu erhalten:

Hinweis: Das angegebene Offset berechnet sich über die Sektorgrösse und den Startsektor des Dateisystems im Image, welches mit dem Befehl fdisk -l RESCUE64-1.15.1-44-ge29fbb1.img inspiziert werden kann.

Anschliessend wird das PBA-Image aus dem CPIO-Paket des RESCUE-Images extrahiert, eingebunden, der enthaltene Kernel signiert und das veränderte PBA-Image wieder ausgehängt:

Jetzt hat man mit der Datei /tmp/usr/sedutil/UEFI64-1.15.1-44-ge29fbb1.img ein aktualisiertes PBA-Image vorliegen, das einen signierten Kernel enthält. Dieses muss nun mit SEDUTIL in den Shadow-MBR der NVME-Laufwerke geladen werden. Wenn im laufenden Linux System die korrekte Version von SEDUTIL (also aus dem gleichen Paket, aus dem auch das PBA stammt) installiert ist, funktioniert das mit folgendem Befehl:

Sollte das laufende Linuxsystem kein kompatibles SEDUTIL besitzten, kann das neue PBA-Image in das ursprügliche CPIO-Paket im RESCUE-Image gepackt werden, dieses auf einen USB Stick geschrieben und dann zur Verwendung des PBA-Images mit der korrekten SEDUTIL Version gebootet werden.

6. Nachbereitung im BIOS (Aktivieren von Secure Boot)

Im ASUS Bios/UEFI kann abschliessend Secure Boot aktiviert werden. Bei ASUS funktioniert das mit der Option "OS Type" und dem Wert "Windows UEFI mode".

Anschliessend den Rechner einmal vollständig ausschalten, damit auch das PBA-System erneut aufgerufen wird und die gesamte Kette getestet werden kann. Im Fehlerfall einfach Secure Boot im Bios/UEFI wieder deaktivieren.

Unter Linux lässt sich das aktivierte Secure Boot wie folgt prüfen:

Unter Windows mit dem Tool msdiag32.

7. Sonstige Anmerkungen

• In Windows 11 sind keine Einstellungen erforderlich. Windows 11 bootet, unabhängig davon ob Secure Boot eingeschaltet oder ausgeschaltet ist. Auch gibt es keine Probleme, wenn Secure Bootnachträglich im Bios/UEFI wieder deaktiviert wird. Ob Secure Boot in Windows 11 aktiv ist, sieht man im Programm msinfo32.
• Soweit mir bekannt ist, sind ein korrekt eingerichtetes Booten per GRUB im EFI Modus und die Nutzung von GPT-Partitionstabellen grundlegende Voraussetzungen für Secure Boot. Beides sollte aber mittlerweile Standard sein.
• Alle Angaben ohne Gewähr! Macht Backups! Insbesondere wenn mit der Hardwareverschlüsselung etwas schief geht, muss im schlimmsten Fall per PS-ID-Revert das komplette Medium unwiderruflich gelöscht werden. Auf jeden Fall das PBA UEFI Image nutzen, welches auch ursprünglich verwendet wurde (ich z.B. verwende einer Version von ChubbyAnt/SEDUTIL.COM, welche aufgrund eines veränderten Password-Hash-Verfahrens mit dem Original SEDUTIL/PBA der Drive-Trust-Alliance und anderen Forks inkompatibel ist. Aber wenn man sowas wie SEDUTIL nutzt, sollte man eigentlich ohnehin immer einen Recovery USB Stick mit exakt der gleichen Version bereithalten, die man zum Zeitpunkt der Verschlüsselung genutzt hatte.