[English]Was lange währt, wird irgendwann gefixt. Im August 2024 versuchte Microsoft den Boot-Lader abzusichern, was aber dazu führte, dass Linux-Systeme u.u. nicht mehr starteten. Mit den Sicherheitsupdates von Mai 2025 hat Microsoft auch das SBAT-Problem, das den Linux-Boot verhinderte, beseitigt.
Rückblick auf das Problem
Microsoft hatte mit den Windows August 2024 Sicherheitsupdates beim Secure Boot das sogenannte Advanced Targeting (SBAT) für alle unterstützten Windows Versionen eingeführt. Ziel ist, zu verhindern, dass kompromittierte oder veraltete Linux EFI (Shim-Bootloader) ausgeführt werden.
Eigentlich ein guter Ansatz, aber Microsoft schrieb damals schon, dass nach Anwendung des SBAT-Updates sich ältere Linux-ISO-Images möglicherweise nicht mehr starten lassen. Es werde eine entsprechend angepasste Linux-Version benötigt. Ich hatte im Blog-Beitrag Windows August 2024-Update legt Linux-Boot lahm erstmalig darüber berichtet.
Es hieß dort noch, dass Dual-Boot-Konfigurationen von Linux und Windows nicht betroffen sein sollten. Zum 22. August 2024 hat Microsoft dann aber auf der Release Health-Statusseite für Windows (z.B. für Windows 11) im Know Issues-Abschnitt den Beitrag August 2024 security update might impact Linux boot in dual-boot setup devices mit Erklärungen veröffentlicht. Redmond bestätigt dort, dass es nach der Installation des Windows-Sicherheitsupdates vom 13. August 2024 (z.B. KB5041585 für Windows 11) zu Linux Boot-Problemen kommen kann. Das Problem soll auftreten, wenn das Dual-Boot-Setup für Windows und Linux dem System aktiviert ist. Linux lässt sich dann nicht mehr starten und scheitert mit der Fehlermeldung:
Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation.
Seit August 2024 waren also betroffene Dual-Boot-Systeme nicht mehr in der Lage, Linux zu starten. Ich gehe daher davon aus, dass betroffene Anwender längst eigene Lösungen verwenden und Microsoft Windows samt Updates gekickt haben. Persönlich bin ich wegen Problemen seit Jahren von Dual-Boot-Lösungen weg und virtualisiere unter Linux Windows bei Bedarf.
SBAT-Problem im Mai 2025 korrigiert
Mit den zum 13. Mai 2025 ausgerollten Sicherheitsupdates für Windows (siehe Patchday: Windows 10/11 Updates (13. Mai 2025)) hat sich Microsoft nun auch des alten Linux-Boot-Problems angenommen. In den Supportbeiträgen der Updates wird unter dem Punkt [Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] der Fix angesprochen. Es heißt, dass mit den Mai 2024-Updates Verbesserungen an SBAT zur die Erkennung von Linux-Systemen vorgenommen werden.
Betroffen sind Systeme mit Windows 10 und 11 sowie den Server-Varianten Windows Server 2012 (R2), 2016, 2019 und 2022. Die Kollegen von Golem stellen hier berechtigt die Frage, ob Betroffene nicht längst die von Microsoft im obigen August 2025-Support-Artikel empfohlenen Workarounds umgesetzt haben. Auch mit den neuen Updates wird eine angepasste Linux-Version für den Dual-Boot benötigt – Microsoft sorgt nur dafür, dass SBAT diese besser erkennt.
Ähnliche Artikel:
Patchday: Windows 11/Server 2022-Updates (13. August 2024)
Windows August 2024-Update legt Linux-Boot lahm
Microsoft äußert sich zu per Windows August 2024-Update lahm gelegtem Linux-Boot
Patchday: Windows 10/11 Updates (13. Mai 2025)
MVP: 2013 – 2016
Wie schön, dass ich mich erst vor knapp zwei Wochen, etwas unfreiwillig, dafür aber ausgiebig mit 'Secure Boot' unter Linux befassen 'durfte' …
Leider ist mein PC dabei abgeschmiert und ich konnte mir nicht alles aus sämtlichen und unzähligen, teilweise veralteten und neueren Quellen aufschreiben, was ich eigentlich wollte und auch nicht die Alternativen davon/dazu, weshalb ich teilweise aus dem Gedächtnis heraus formulieren muss!
Erstmal: Microsoft mag hier eine Teilschuld haben, ich sehe das Problem aber eher an einer anderen Stelle! (wie immer… wird aber trotzdem komplett auf MS geschoben und alles andere weiterhin abgestritten werden!)
Laut den 'Issue Details' aus dem o.g. 'Release Health' Beitrag konnte das Problem nur bei der Installation des August 2024 Sicherheitsupdates bzw. des Previews davon auftreten und hätte, wie angegeben, bei Dual-Boot-Systemen den entsprechenden Teil des Updates überhaupt nicht durchführen sollen.
Jetzt ist aber die Erkennung von Dual-Boot bei manchen "customized methods of dual-booting" fehlgeschlagen und die entsprechende Sicherheitsrichtlinie wurde trotzdem geschrieben. Ich weiß nicht genau, was hier passiert ist, aber… Moment! "Linux" und "angepasste Methoden"!? Ja super!
Mit dem September 2024 Update wurde die Funktion vorerst wieder entfernt und das Problem somit umgangen ('Workaround') und was hier jetzt genau gefixt wurde lässt sich, Microsoft typisch, natürlich nicht herausfinden, denn was "Verbesserungen bei der Erkennung von Linux Systemen" genau bedeuten soll kann man nur mutmaßen, es scheint sich aber zumindest dem Wortlaut nach nicht unbedingt auf Dual-Boot-Systeme zu beziehen und wenn man Infos dazu sucht, dreht man sich im Kreis zwischen immer denselben Behauptungen von denselben IT-Seiten!
Das Update muss irgendwann aber auf jeden Fall installiert werden, denn es betrifft wohl hauptsächlich sicherheitsanfällige Linux Bootloader. Ich schätze, dass das Update jetzt nicht nur 'Customgefrickelt' besser erkennt, sondern (zusätzlich) prüft, ob der/die erkannten Linux Bootloader bei Multi-Boot die neuen Einstellungen vertragen oder nicht.
Linux Secure Boot läuft (in etwa) folgendermaßen ab (vor SBAT Update):
– UEFI prüft den (von Microsoft signierten) Shim Bootloader auf Signierung und zurückgezogene Zertifikate und lädt den dann (oder halt auch nicht s.o.)
– Der Shim Bootloader prüft und lädt dann wiederum den Grub (Stufe 2) Bootloader aber nur, wenn das Gegenstück zu dessen Signierschlüssel oder dessen Hashwert in der 'machine owner key' liste (MokList) vorhanden ist (bei vollverschlüsselten Systemen wird erst Grub Stufe 1.5 statt 2 geladen)
– (Optional: Bei verschlüsselten Systemen lädt Grub Stufe 1.5 nach Entschlüsselung den Grub Stufe 2 Bootloader)
– Der Grub Bootloader lädt den Linux Kernel usw.
Nach dem SBAT Update passiert zusätzlich folgendes:
Alte Shim Bootloader laden nicht mehr, weil sie entsprechend EFI seitig geblockt sind, denn nur neuere Shim Bootloader prüfen den nachfolgenden Grub Bootloader und zwar nicht nur auf Signierung, sondern zusätzlich auf SBAT Metadaten (Version, Alter, Sicherheitsprobleme…)
Das Problem lies/lässt sich übrigens sehr einfach beheben:
Secure-Boot ausschalten, Linux starten, Update durchführen, runterfahren, Secure Boot an, Booten
Funktionert aber bei vielen nicht! Warum könnte man sich da fragen, denn
Laut Ventoy benötigt man Shim 15.8
[ https://github.com/ventoy/Ventoy/issues/2692#issuecomment-2031412234 ]
Release Januar 2024!
[ https://github.com/rhboot/shim/releases/tag/15.8 ]
In Fedora seit März 2024!
[ https://kojipkgs.fedoraproject.org/packages/shim/15.8/2/x86_64/ ]
In Ubuntu seit August 2024 (24.04.1)!
[ https://forum.ubuntuusers.de/post/9444790/ ]
Der blockt Grub < 2.06 wegen der Sicherheitslücke CVE-2022-2601!
[ https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-linux-boot-issues-on-dual-boot-windows-systems/ ]
Geschlossen Februar 2022!
[ https://bugzilla.redhat.com/show_bug.cgi?id=2112975#c0 ]
Und jetzt die Preisfrage:
Wenn man schon die böse, böse Secure Boot Funktion vom schlimmen Microsoft verwendet über die die Linuxer seit Jahren in Foren rumheulen, aber von den Verantwortlichen trotzdem implementiert wurde und alle irgenwie eingeschaltet haben und die dann entsprechend dafür sorgt, dass problematische Software nicht geladen werden kann, warum beschwert man sich dann darüber, aber nicht bei 'seiner' Distribution, die es bis August 2024 nicht geschafft hat, einen Bootloader zu implementieren, der seit Januar 2024 verfügbar ist und eine Sicherheitslücke verhindert, die seit Februar 2022 geschlossen ist?
SBAT wurde übrigens von Microsoft zusammen mit der Open Source Gemeinde entwickelt um die Sicherheit zu erhöhen und um selektiv anfällige Komponenten zu blockieren!
Anderer Lösungen wären übrigens signierte shimx64.efi und grubx64.efi aus anderen Distributionen (z.B. o.g. Fedora) nach /boot/efi/EFI/'Distri' (o.ä.!) zu kopieren. Oder nur Erstere und dann einen eigenen Grub bauen (z.b. mit grub-mkstandalone) und dessen hash in der o.g. MoKList (mokutil) abzulegen oder direkt ein eigenes Schlüsselpaar zu generieren, mit dem Privaten signieren und den Öffenlichen entsprechend alternativ in die MoKList schreiben.
Oder einfach das böse Secure Boot deaktiveren oder das 'Compatibility Support Module' (CMS) aktivieren! Dann aber nicht beschweren, falls sich doch mal persistente Schadsoftware manifest im EFI breitmacht und man dann die Hardware wegschmeißen darf!
PS Boot-Lader finde ich irgendwie einen schönen Schreibfehler! :)
Der Fehler ist gestern beim Update
2025-07 Kumulatives Update für Windows 11 Version 24H2 für x64-basierte Systeme (KB5062553)
und heute beim Update
2025-07 Kumulatives Update für .NET Framework 3.5 und 4.8.1 für Windows 11, Version 24H2 für x64 (KB5056579)
bei mir wieder auf der Workstation und meinem Notebook aufgetreten.
Windows startet entweder nach dem Update komplett durch, ohne den Bootmanager Grub überhaupt anzuzeigen oder aber Linux startet, ohne dass der Bootmanager Grub überhaupt angezeigt wird. So langsam ist es lächerlich, was Microsoft da betreibt.
Wenn das nun noch mal vorkommt, werde ich Grub noch mal neu setzten, vielleicht bewirkt das etwas.