Secure Boot: Microsoft erweitert Workaround für parallele Linux-Installationen

Das Update für Windows 10 und 11 vom 13. August hat nicht nur diverse Live-Linux-Systeme auf USB-Sticks lahmgelegt. Weil die im Update enthaltene Erkennung von parallel installierten Linux-Systemen in einigen Szenarien versagt hat, wurde auch manches bereits installierte Linux-System lahmgelegt. Nun hat Microsoft einen zweiten Workaround veröffentlicht, der zuvor gesperrte Installationen wieder booten lassen soll. Doch dieser greift zu kurz, er entfernt lediglich die Sperren komplett und hebelt damit Secure Boot aus. Um den Zustand vor dem Update wiederherzustellen, ist ein zusätzlicher Schritt erforderlich.

Mit dem in KB5041571 (Windows 11) respektive KB5041580 (Windows 10) beschriebenen Update hat Microsoft das von der Open-Source-Gemeinde entwickelte Secure Boot Advanced Targeting (SBAT) auf Windows-PCs nachgerüstet. Damit sollten ältere und unsichere Bootloader blockiert werden. Da Linux-Bootloader bereits SBAT unterstützen, verwendet Microsoft die neue Technik, um wertvollen Platz in der DBX-Blacklist des UEFI-BIOS zu sparen, die bei früheren Bootloader-Sperrungen ausschließlich genutzt wurde.

Dem Plan nach sollte das nur auf Rechnern ohne Linux-Parallelinstallation passieren, damit das Windows-Update nicht der Linux-Installation ins Gehege kommt. Stattdessen sollen verwundbare Bootloader im Zuge der regelmäßigen Distributions-Updates gesperrt werden und nicht etwa durch Windows-Updates. Die Idee ist prinzipiell gut, denn ohne SBAT einzuspielen würden reine Windows-PCs weiterhin unsichere Linux-Bootloader etwa vom USB-Stick starten, sodass ein Angreifer Secure Boot durchbrechen könnte. Die einzige Alternative wäre, die eigentlich per SBAT zu sperrenden Linux-Bootloader doch wieder auf die DBX-Sperrliste zu setzen und diese damit weiter aufzublähen.

SBAT-Update verhindern

Durch die unzuverlässige Linux-Erkennung kam es nun aber doch dazu, dass das Windows-Update auf manchen Rechnern die SBAT-Listen der Linux-Systeme überschrieb und sie damit sperrte. Microsofts erster Workaround, um dieses Szenario zu verhindern, setzt schon bei der Installation des kumulativen Updates vom 13. August an. Diese erfordert zum Abschluss einen Neustart des Rechners. Ist der Neustart noch nicht erfolgt, so können Sie über folgenden Registry-Eintrag verhindern, dass SBAT eingespielt wird:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD

Den Neustart zum Abschluss des Updates führen Sie dann erst aus, wenn der Eintrag erfolgt ist.

Rolle Rückwärts

Für den Fall, dass das Windows-Update bereits zu einem früheren Zeitpunkt eingespielt wurde, hat Microsoft nun einen zweiten Workaround im Windows Release Health Center ergänzt. Verhindert SBAT bereits, dass Linux bootet, so müssen Sie im UEFI-BIOS zunächst Secure Boot abschalten. Allerdings nicht, bevor Sie nicht Ihren BitLocker-Wiederherstellungsschlüssel aufgeschrieben, ausgedruckt oder auf USB-Stick gesichert haben: Die Laufwerksverschlüsselungen reagiert mitunter empfindlich auf Änderungen bei Secure Boot und verlangt dann die Eingabe des Schlüssels, damit Sie Ihr Windows wieder starten können.

Ohne Secure Boot können Sie nun Ihr installiertes Linux von Festplatte wieder starten. Öffnen Sie ein Terminal und prüfen Sie zunächst, ob tatsächlich die SBAT-Sperrliste von Microsoft eingespielt wurde:

mokutil --list-sbat-revocations

Achten Sie dabei auf den Timestamp, dieser lautet bei Microsofts SBAT-Update 2024010900. Um die Sperrliste wieder zu löschen, verwenden Sie den in Microsofts zweitem Workaround genannten Befehl:

sudo mokutil --set-sbat-policy delete

Wichtig ist nun ein Neustart des Rechners, damit die Änderung wirksam wird – wiederum mit deaktiviertem Secure Boot. Zurück im Terminal unter Linux überprüfen Sie, ob die Liste erfolgreich gelöscht wurde:

mokutil --list-sbat-revocations

Der Timestamp ist nun ein anderer, älterer als zuvor, außerdem gibt es keine Einträge für Shim und Grub mehr. Hat es im ersten Mal nicht geklappt, versuchen Sie nun nocheinmal, die SBAT-Liste zu löschen.

Lücke schließen

Damit ist SBAT und in der Folge auch Secure Boot allerdings vollständig ausgehebelt und Ihr Rechner bootet sämtliche Bootloader wieder, die zuvor bereits von Ihrer Linux-Distribution über Updates der SBAT-Sperrliste blockiert wurden. Würden Sie Secure Boot nun aktivieren, wäre nur ein Teil der Sperren wirksam. Um den Zustand von vor dem Windows-Update wiederherzustellen, spielen Sie mit folgendem Befehl die SBAT-Sperrliste Ihrer Linux-Distribution wieder ein:

sudo mokutil --set-sbat-policy latest

Jetzt ist wiederum ein Neustart fällig, nachdem Sie sich erneut die aktuell gültige SBAT-Sperrliste anzeigen lassen:

mokutil --list-sbat-revocations

Finden Sie nun neben der Zeile mit dem Timestamp auch noch jeweils mindestens eine Angabe zu Shim und Grub, war die Aktualisierung erfolgreich und Sie können Secure Boot im UEFI-BIOS wieder aktivieren – sofern Sie das noch wollen. Damit Windows künftig bei SBAT nicht mehr dazwischenfunkt, müssen Sie noch den folgenden Registry-Schlüssel unter Windows setzen:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD

So bleibt Linux die Aktualisierung der SBAT-Sperrlisten vorbehalten und Windows kümmert sich um etwaige anfällige Windows-Bootloader.

(mid)