Seit neun Monaten konnte es vorkommen, dass der Windows/Linux-Dual-Boot nicht mehr funktionierte, weil Bootloader blockiert wurden, die durch eine kritische Sicherheitslücke gefährdet waren.
Wie Microsoft selbst im Patch-Tracking-Protokoll erklärt, hatte die Bereitstellung des Sicherheitspatches(KB5041160) für viele Benutzer, die Windows/Linux-Dual-Boot lieben, zu einem substanziellen Problem geführt. In vielen Fällen war der Dual-Boot einfach nicht mehr funktionsfähig und es wurde eine Fehlermeldung wie " Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Vi olation" ( Etwas ist ernsthaft schief gelaufen: SBAT-Selbstprüfung fehlgeschlagen: Verletzung der Sicherheitsrichtlinien ). Ein Problem, das schon von Grund auf ärgerlich ist, aber auch noch so lange andauert, dass es bis August 2024 zurückreicht.
Microsoft hat nun mit dem Update KB5058385 vom 13. Mai bestätigt, dass der Fehler nun der Vergangenheit angehört. Die Korrektur ist in diesem Update enthalten, das seit einigen Tagen bereitgestellt wird und einen funktionierenden Neustart ermöglicht, ohne dass Sie etwas tun müssen. Es ist zu beachten, dass der Patch das Problem auf allen Systemen behebt, die betroffen waren, d. h. Windows 10, Windows 11 sowie Windows Server. Wie Microsoft erklärt, " behebt sie die unerwünschten Auswirkungen des SBAT-Updates ".
Wir erinnern uns, dass das Update KB5041160 vom August letzten Jahres nicht dazu gedacht war, Multiboot-Konfigurationen durcheinander zu bringen. Es sollte vielmehr Bootloader blockieren, die durch eine kritische GRUB2-Sicherheitslücke (CVE-2022-2601) gefährdet sind. Das Problem war, dass bei einigen Linux-Distributionen - was erklären würde, warum nicht alle Dual-Boot-Nutzer betroffen waren - die korrigierte Version von GRUB2 nicht eingebettet oder, was letztlich fast auf dasselbe hinausläuft, nicht von Microsoft signiert worden war. Dies führte dazu, dass der Secure-Boot-Prozess nicht mehr richtig funktionieren konnte. Microsoft reagierte erst spät - gelinde gesagt -, war aber eindeutig nicht der einzige Schuldige in dieser Geschichte.
