Zerstörte Bootloader durch Windows Update

Seit ein paar Tagen gibt es Meldungen, dass durch ein Windows Update zahlreiche Linux-Distributionen, Installationsmedien und Live-Systeme von Linux-Distributionen nicht mehr starten. Ursache sind durch  Windows gesperrte Bootloader, denn das Update füge eine Einstellung zum Secure Boot Advanced Targeting (SBAT) auf Geräten hinzu. Damit sollen nach Meinung von Microsoft veraltete, verwundbare Bootmanager  blockiert werden. Das geht gar nicht. Alles in Allem ist das ein arrogantes und kein seriöses Verhalten von Microsoft, denn wie wäre es andersherum? Die Installation eines Linux würde dazu führen, dass Windows nicht mehr startet, weil Linux-XYZ meint, dass Windows oder dessen Bootloader unsicher sind?

Angeblich betrifft das auch topmoderne Distributionen wie Ubuntu 24.04 LTS oder darauf basierende Live-Systeme wie Desinfec’t. Noch schlimmer – das SBAT-Update soll offiziell nicht auf Geräten installiert werden, auf denen eine Dual-Boot-Konfiguration (wie bei mir) zum Einsatz kommt. Aber es gibt mittlerweile zahlreiche Meldungen, dass trotzdem bei Dual-Boot-Systemen Linux nicht mehr startet und eine Fehlermeldung „Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation“ anzeigt. Angeblich wäre nach Microsoft auf solchen Geräten eine Erkennung fehlgeschlagen, da dort etwa angepasste Dual-Boot-Optionen genutzt werden, wodurch die SBAT-Änderungen ergänzt würden, obwohl das nicht geschehen sollte.

Mit anderen Worten – Microsoft hat Schrott verbreitet. Nichts anderes ist dieses fehlerhafte (denn die ungenügende Erkennung ist einfach nur ein gravierender Fehler) Update. Überhaupt – wenn ich Dual-Boot habe, hat sich ein Betriebssystem komplett aus dem anderen Betriebssystem rauszuhalten. Es kann nicht sein, dass der Schwanz mit dem Hund wedelt.

Ich habe jetzt erst einmal das aktuelle Windows Update auf meinem Rechner abgelehnt. Linux ist für mich das Hauptsystem und die wenigen Male, in denen ich auf meinem Hauptrechner Windows noch starten muss, sind selten wichtig. Bevor ich das Risiko eingehe, dass Linux da nicht mehr startet, verzichte ich lieber auf Windows. Für die Fälle, wo ich Windows dennoch brauche (etwa wegen Access oder .NET-Programmierung) habe ich noch ältere Windows-PC ohne Dual-Boot, die dafür ausreichen.

Microsoft hat mittlerweile einen ziemlich umständlichen und unbefriedigenden Workaround veröffentlicht oder man kann Secure Boot deaktivieren. Dabei kann es aber zu Problemen mit Bitlocker kommen (die hatte ich ganz am Anfang nach dem Kauf meines Rechners und erstem Einrichten von Dual-Boot auch schon) und man muss sicherstellen, dass Sicherheitskopien der Bitlocker-Wiederherstellungsschlüssel vorhanden sind, da Windows mitunter beim Start mit der Abfrage dieser Schlüssel auf Änderungen bei Secure Boot reagiert.

Wobei das Problem vermutlich tiefer liegt, denn Secure Boot und das neue UEFI-Bios sind m.E. für die meisten Anwender ungeeignet und vom Konzept praxisfern. So etwas kann man auf großen Flotten mit Firmenrechnern, die von spezialisierten Admins verwaltet werden, erzwingen, aber nicht im normalen Alltag.

EDIT
Auf Computerbild (ja – oh Wunder) habe ich einen Hinweis zu einem brauchbaren Workaround gefunden:

Übergangslösung aus der Linux-Community
Noch hat sich Microsoft zu den Problemen nicht geäußert. Eine Übergangslösung stammt aus einem Hilfsforum der Distribution Linux Mint. Demnach sollen Betroffene die folgenden Schritte durchführen, um die gewohnte Funktionalität wiederherzustellen:

Secure Boot im UEFI ausschalten.
Via Dual-Boot Linux starten.
Das Terminal öffnen und folgenden Befehl (ohne Anführungszeichen) eingeben: "sudo mokutil --set-sbat-policy delete".
Den PC neu starten und erneut in Linux einloggen.
Den PC ein weiteres Mal neu starten und Secure Boot im UEFI wieder aktivieren.


Im Anschluss sollte der PC via Dual-Boot wieder wie gewohnt funktionieren. Es bleibt abzuwarten, wann der US-Konzern das Problem mit einem weiteren Patch behebt.