UEFI-Boot-Einträge und Secure-Boot-Status unter Linux und Windows

Ziel

Die Boot-Eintragsliste der UEFI-Firmware prüfen und bei Bedarf reparieren sowie den Secure-Boot-Status bestätigen, und zwar auf einem Linux- oder Windows-System, das nicht von der erwarteten Platte oder dem erwarteten Loader startet.

Voraussetzungen

UEFI-Firmware (kein Legacy-BIOS); root unter Linux bzw. eine Eingabeaufforderung mit erhöhten Rechten unter Windows, entweder aus dem laufenden System, von einem Rettungsmedium oder aus dem Firmware-Setup; unter Linux muss efivarfs eingehängt sein (bei per UEFI gestarteten Systemen der Normalfall).

Schritte

1. Einträge unter Linux auflisten: efibootmgr -v zeigt Nummer, Bezeichnung und Gerätepfad jedes Eintrags, die BootOrder, der die Firmware folgt, sowie BootCurrent, den Eintrag, der für diesen Start verwendet wurde. Einen Eintrag erstellt man mit efibootmgr -c -d <disk> -p <partition> -L "<label>" -l '\EFI\<dir>\shimx64.efi' (-c nimmt den neuen Eintrag auch in die BootOrder auf, normalerweise an erster Stelle), löscht ihn mit efibootmgr -b <bootnum> -B und ändert die Reihenfolge mit -o <bootnum>,<bootnum>,.... Jede Änderung schreibt die Firmware-Variablen sofort; einen separaten Schritt zum Übernehmen gibt es nicht. Zuerst die Ausgabe von -v festhalten, damit sich die alte Reihenfolge mit -o wiederherstellen lässt.
2. Um einen neuen Eintrag einmalig zu testen, ohne die Reihenfolge zu ändern, efibootmgr -n <bootnum> (BootNext) setzen; die Firmware verwendet ihn nur für den nächsten Start und fällt danach auf die BootOrder zurück.
3. Unter Windows listet bcdedit /enum firmware die Einträge des Firmware-Boot-Managers auf (zu unterscheiden von den OS-Loader-Einträgen eines einfachen bcdedit /enum); in PowerShell sind Bezeichner wie '{fwbootmgr}' in Anführungszeichen zu setzen. Windows legt seinen eigenen Eintrag normalerweise mit bcdboot <drive>:\Windows (mit erhöhten Rechten) neu an, statt ihn direkt zu bearbeiten.
4. Startet das System nach einer Neuinstallation des Bootloaders im Firmware-Setup oder mit dem falschen Betriebssystem, ist meist ein fehlender oder nicht an erster Stelle stehender Eintrag die Ursache. Abhilfe schafft efibootmgr -o oder die Boot-Reihenfolge-Einstellung der Firmware.
5. Secure Boot prüfen, bevor es für einen Fehler wie «not trusted» verantwortlich gemacht wird: unter Linux mokutil --sb-state; unter Windows liefert Confirm-SecureBootUEFI in einer PowerShell mit erhöhten Rechten $True oder $False und gibt bei BIOS oder nicht unterstützter Firmware "Cmdlet not supported on this platform" aus.
6. Bei aktiviertem Secure Boot sieht die Linux-Kette so aus: Die Firmware vertraut einem signierten shim, und shim vertraut zusätzlich Machine Owner Keys (MOK). mokutil --import <key.der> verlangt ein Einmalpasswort und hinterlegt den Schlüssel nur zur Registrierung; beim nächsten Start fordert der MokManager von shim an der Konsole auf, die Registrierung mit diesem Passwort zu bestätigen, es muss also jemand an der Konsole sein. Das Erzeugen und Signieren von Schlüsseln behandelt dieser Artikel nicht.
7. Nach jeder Änderung neu starten und mit efibootmgr -v oder bcdedit /enum firmware bestätigen, dass die Reihenfolge übernommen wurde.

Erwartetes Ergebnis

Der gewünschte Eintrag ist vorhanden und steht in der BootOrder an erster Stelle. Der gemeldete Secure-Boot-Status entspricht den Anforderungen der Workload – vorzugsweise aktiviert, wobei der Schlüssel eines Drittanbieter-Moduls über MOK registriert wird, statt Secure Boot auszuschalten.

Grenzen und Prüfbasis

efibootmgr ändert den NVRAM direkt: Das Löschen des falschen Eintrags wirkt sofort, daher vor -B die Boot-Nummern in der Ausgabe von -v prüfen. Firmware-Implementierungen gehen unterschiedlich mit hinzugefügten oder fehlerhaften Einträgen um (manche verwerfen oder sortieren sie um), das Verhalten ist deshalb auf der tatsächlichen Hardware zu bestätigen.