[English]Die August 2024-Updates für Windows haben bei Linux-Nutzern für einen Kollateralschaden gesorgt. Durch eine Umstellung des Boot-Mechanismus auf Secure Boot Advanced Targeting (SBAT) verweigerte der Linux-Boot-Lader bei Dual-Boot-Systemen im Anschluss an die Update-Installation den Start. Nun hat Microsoft sich zu den Gründen geäußert und versucht, das Ganze zu erklären. Ergänzung: Das Problem könnte auch Backup-Lösungen betreffen.
Anzeige
Rückblick auf das Linux-Boot-Problem
Microsoft hat 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. In den betreffenden Supportbeiträgen heißt es dazu:
[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.
Problem ist aber, dass es – entgegen der Aussage Microsofts – auch Dual-Boot-Systeme getroffen hat. Und es waren auch aktuelle Linux-Distributionen betroffen. Ich hatte das Thema im Blog-Beitrag Windows August 2024-Update legt Linux-Boot lahm aufgegriffen.
Microsoft äußert sich
Microsoft hat zum 22. August 2024 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.
Der Windows-Hersteller erklärt im Supportbeitrag, dass das Windows-Sicherheitsupdate vom August 2024 eine Secure Boot Advanced Targeting (SBAT)-Einstellung auf Geräte anwendet, auf denen Windows läuft. Ziel soll es sein, alte, anfällige Bootmanager zu blockieren. Auch dort wird (fälschlich) wiederholt, dass dieses SBAT-Update nicht auf Geräte angewendet wird, auf denen Dual-Boot erkannt wird. Denn in diesem Fall dürfte es ja keine Probleme mit Dual-Boot-Installationen geben.
Anzeige
In einem Satz wird aber klar, dass bei Microsoft "der Wunsch, Vater des Gedankens war", denn Redmond musste kleinlaut eingestehen "Auf einigen Geräten hat die Dual-Boot-Erkennung einige benutzerdefinierte Dual-Boot-Methoden nicht erkannt und den SBAT-Wert angewendet, obwohl er nicht hätte angewendet werden dürfen." Es ist die vornehmere Umschreibung von "wir haben es mal wieder in bewährter Weise kolossal verkackt".
Real-Satire gefällig?
Ein bisserl Real-Satire schimmert dann in Microsofts Aussage "Sie können überprüfen, ob die SBAT unter Linux aktiviert ist, indem Sie die folgenden Schritte ausführen" durch. Denn wer in Boot-Probleme gerauscht ist, weiß inzwischen, dass er betroffen ist und steht vor dem Problem, auf dem nicht mehr bootenden Linux die folgenden Probleme ausführen zu sollen:
- Öffnen Sie Ihr Terminalprogramm
- Geben Sie mokutil –sb-state ein und drücken Sie Enter
Dann soll der Nutzer in der Ausgabe nach dem SBAT-Status suchen. Ist SBAT aktiviert, wird dies angezeigt.
Secure Boot abschalten und SBAT löschen
Wer das August 2024-Update installiert hat und in das Linux-Boot-Problem gelaufen ist, muss den Secure-Boot im UEFI abschalten. Wie das genau passiert, ist vom UEFI-Hersteller abhängig (bei manchen Mainboards ist Secure Boot nicht mehr abschaltbar). Danach sollte sich Linux booten und der nachfolgende Befehl in einem Terminalfenster eingeben lassen:
sudo mokutil --set-sbat-policy delete
Die Ausführung des obigen Befehls erfordert die Eingabe des root-Passworts für das Linux-System. Ob das Ganze geklappt hat, lässt sich mit folgendem Terminal-Befehl prüfen:
mokutil --list-sbat-revocations
Sofern kein SBAT mehr angezeigt wird, kann die Maschine neu gestartet und der Secure Boot im UEFI erneut eingeschaltet werden. Nun sollten sowie Linux als auch Windows wieder im abgesicherten Boot-Modus starten können.
SBAT-Installation verhindern
Um ein erneutes SBAT-Desaster durch die Update-Installationen zu verhindern, hat Microsoft einen besonderen Kniff verraten. Unter Windows sollte folgender Befehl für einen Eintrag in der Registrierung sorgen:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD
Der DWORD-Wert OptOut=1 unter SBAT verhindert zukünftig, dass Windows-Update die betreffenden SBAT-Einstellungen bei den betreffenden Systemen manipulieren.
Betroffen waren …
Microsoft hat auch bestätigt, welche Windows-Updates bzw. Windows-Versionen von diesem SBAT-Deaster betroffen waren. Es tangiert sowohl Clients als auch Server:
- Windows 11 Version 21H2 – 23H2
- Windows 10, Version 21H2 – 22H2
- Windows 10 Enterprise 2015 LTSB
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
Aufgefallen ist mir, dass Microsoft Windows 10 Enterprise 2016 LTSB in seinem Support-Beitrag nicht aufführt, während Windows Server 2016 als betroffen genannt ist. Ich gehe davon aus, dass Microsoft schlicht die Windows 10-Versionen in der Aufstellung vergessen hat. Aktuell untersuchen die Microsoft-Leute das Problem zusammen mit den Linux-Partnern und plant ein Update bereitzustellen. Wann dies der Fall ist, bliebt aktuell offen.
Backup-/Verschlüsselungs-Lösungen betroffen
Ergänzung: Das Problem könnte auch Backup-Lösungen betreffen, wenn die Lösung ein Linux-Betriebssystem booten muss, um das Backup zurückzuspielen. Ein Blog-Leser informierte mich per Mail zudem über eine andere Klippe und schrieb: "In unserem Unternehmen ist das auch wichtig, das unser Festplattenverschlüsselungssoftware-Hersteller (nicht Microsoft) uns per Newsletter informiert hat, dass uns nach Installation der Patches das gleiche Schicksal blüht, wie bei Linux-Dualboot."
Die Einträge in der Registry, die oben genannt wurden, ist für diesen Leser bei mehreren tausend Geräten keine Option. Den Leser treibt nun die Frage um: "Wenn jetzt das Ausführen der SBAT-Änderung übersprungen wird, und die die August-Patches problemlos installiert wurden – was passiert, wenn er in x Monaten nach dem Updaten der Festplattenverschlüsselungssoftware den Registry-Wert wieder entfernt?"
Der Leser will ich ja nicht durch temporäres Pausieren des SBAT-Updates für immer damit leben müssen, dass unsichere GRUB2-Versionen zugelassen sind, die eine Lücke enthalten, womit Secure Boot ausgehebelt werden kann.
Die Frage die sich stellt: "Zieht Windows bei entferntem Registry-Eintrag dann das SBAT-Update im Rahmen des nächsten regulären Patchday per kumulativem Update doch wieder? Leider sei Microsoft da nicht sehr auskunftsfreudig, meint der Leser und fragt, wie andere Administratoren das sehen?
Der Leser merkt noch an, dass Microsoft diesen Patch nicht aus Spaß veröffentlicht habe. Mit dem Update sollten lediglich veraltete GRUB2-Versionen blockiert werden, die anfällig für CVE-2022-2601 sind. Wobei der Leser den Gedanken hatte: "Wie kann es sein, dass scheinbar so viele Installationen noch mit anfälligem/veraltetem GRUB2 arbeiten?
Zu dieser Aussage kann ich nichts finales sagen, aber es ist auffällig, dass selbst ein aktuelles Ubuntu streikt und demnach mit einem "veralteten GRUB2-Loader" daher kommt. Kommt mir spanisch vor.
Ähnliche Artikel:
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (13. August 2024)
Windows Server 2019/Windows 10 Enterprise 2019 LTSC: Performance-Probleme mit Update KB5041578
Windows August 2024-Update legt Linux-Boot lahm
Microsoft äußert sich zu per Windows August 2024-Update lahm gelegtem Linux-Boot
Anzeige
Dual Boot Systeme sind die Non-Binär-Seuche der Informationstechnik, heute mehr denn je. Wenn jemand schon grottiges Windows braucht(e), war/ist es wohl kein nennenswerter Leidenszuwachs, da noch schnell ein Cygwin draufzubügeln oder eben ein Windows Subsystem for Linux (WSL), das ja auch schon geraume Zeit existiert.
Der Rest hat nur Linux oder BSD auf der Kiste, fertig! Deshalb kein Mitleid mit 'Windows August 2024-Update-Opfern'.
Mag sein, daß Cygwin oder WSL einige Probleme lösen mag, ich hatte viele Jahre Cygwin benutzt, aber Cygwin kann nicht einfach Linux Programme ausführen. WSL(2) ist leider auch sehr begrenzt. Statt Dual-Boot (warum eigentlich) ist es besser entweder das eine oder das andere Betriebssystem in einer VM auszuführen. Mal abgesehen davon betreibt M$ Computersabotage, wenn die Liste ohne meine Zustimmung geändert wird. Das läßt sich auch nicht mit EULA oder AGB regeln.
> Mal abgesehen davon betreibt M$ Computersabotage, wenn die Liste ohne meine Zustimmung geändert wird. Das läßt sich auch nicht mit EULA oder AGB regeln.
Leider falsch. Formal hast Du die Zustimmung mit der EULA bei Installation selbst gegeben. Du könntest höchstes auf Unlauterbarkeit plädieren. Ich habe genau das bei mir im Blog betrachtet:
https://blog.jakobs.systems/blog/20240820-secure-boot-suendenfall/
>>> Ich habe genau das bei mir im Blog betrachtet <<<
Wie Sie dort ja schreiben: "Das ist meine persönliche rechtliche Einschätzung ohne Anspruch auf Richtigkeit und Allgemeingültigkeit." Womit eigentlich alles gesagt ist.
Wenn Sie sich schon so weit aus dem Fenster lehnen, sollten Sie schon auch Rechtsprechung und juristische Kommentierungen heranziehen. Ich empfehle Ihnen grundsätzlich ein Herangehen nach dem Vorbild von Abschnitt "V. Regelung der Gewährleistung und Haftung durch AGB" in (1), S. 183 ff.
(1) https://www.itm.nrw/wp-content/uploads/Skript_IT-Vertragsrecht_Stand_Juni_2023.2.pdf
Vielen Dank für den Hinweis und des Skriptes der ITM. Wenn Sie aber ein Herangehen nach dem Abschnitt V. vorschlagen, dann hätten Sie aber entweder mein Blog oder das Skript lesen sollen.
Meine Kernaussage:
> Nach meinem Dafürhalten sind Lizenzverträge mit Generalklauseln und einem auffälligen Missverhältnis der Parteien sittenwidrig.
wird auf den Seiten 183 ff genauso gesagt und zwar prominent bereits in der Einleitung:
> Bei der Verwendung allgemeiner Geschäftsbedingungen kommt für den Bereich zwischen B2C und B2B neben §§ 138 (…) in Betracht.
Im Skript werden sogar einige der Generalklauseln als Beispiele zitiert wie beispielsweise "Der Vertragsschluss erfolgt unter Ausschluss jeder Gewährleistung".
Es folgen natürlich noch weitere Details der Unterscheidung zwischen B2B und B2C, die Würdigung der Nacherfüllung und der verbundenen Kosten, Haftungsausschlüsse etc. Diese sind natürlich zu prüfen, was ich dem Medium "Blog" geschuldet, dem Leser erspart habe.
Ich sehe daher nach Durchsicht keinen Widerspruch zu dem von Ihnen so betont anheim gelegten Skriptes. Für Ihre konkretisierten Vorschläge oder Vorwürfe habe ich weiterhin selbstverständlich ein offenes Ohr.
Jo, ist eben auch ein schwieriges Unterfangen. Wenn man ein System sicherer machen möchte, bleibt meist irgendwas auf der Strecke. Unabhängig davon, ob das Microsoft nun im konkreten Fall gut oder schlecht umgesetzt hat.
Ein System, das sich gar nicht mehr starten lässt, ist natürlich besonders sicher. Vergleichbar einem mit Ransomware verschlüsselten — da kommt auch keiner mehr an die Daten ran.
Ich habe ein Verständnisproblem. Wenn das ganze Sicherheitstheater mit einem Registry Eintrag einfach zu verhindern ist. Warum hat man den Scheiß eigentlich gestartet?
Wenn ich denn Windows noch benutzen würde, käme ich mir ziemlich verarscht vor.
Es schockiert mich etwas – so entnehme ich es zumindest dem Artikel, dass es bereits Motherboards geben soll, bei denen man secure boot nicht mehr abschalten kann.
Worauf soll man denn inzwischen noch alles achten beim Kauf von Komponenten.
Führt dazu, dass sich zumind. mein Konsumverhalten (was eh schon grundsätzlich vom Mainstream abweicht) zu noch restriktiver gegenüber einzelnen Betriebssystemen ändert.
Dieser ganze "SecureBoot"-Mist ist doch auch nur monopolistische Gängelung und bringt mittlerweile erwiesenermaßen dem 08/15-Otto-Normalnutzer mehr Probleme anstatt Sicherheit – Dinge, die die Welt NICHT braucht! 🤷♂️
Für die, die nicht schnell mal viele hunderte oder gar tausende Euro für einen linuxfähigen Computer locker machen wollen oder können, wird es in den nächsten Jahren wohl enger werden. Bei viele Anbietern, z.B. von Notebooks, ist Linux ja mehr oder weniger notgedrungen geduldet (d.h. man hat es noch nicht geschafft, den Rechner genug zu verdongeln) – vieles in der Hardware lässt sich nicht so nutzen wie unter Windows, dem man doch gerne die Treiber dafür spendiert. Und das Problem betrifft ja oft schon Leute, die sich mit der Materie auseinandersetzen wollen.
Aber vielleicht gibt das einen Schub für die Anbieter von Hardware, die Geräte explizit für Linux herstellen (aber unter denen vielleicht doch auch Windows läuft ;)). Die gibt es ja, aber eben nicht zum Low-End-Preis.
Wer es vermeintlich einfacher möchte, greift dann halt auch gern zu Apple. Auch nicht gerade Schnäppchenangebote…
>>> Für die, die nicht schnell mal viele hunderte oder gar tausende Euro für einen linuxfähigen Computer locker machen wollen oder können, … <<<
Das ist haltlose Angstmacherei!
Ich begegne immer öfter Leuten, die sich von ihren Kindern oder Bekannten gebrauchte und überholte Businessnotebooks (ab 200 Euro) aus Firmenflotten mit einem schlanken Linux Desktop hinstellen liessen. Das sind zwar meist bessersituierte Akademikerhaushalte, ich sehe aber keinen Grund, weshalb solche Konfigurationen nicht auch über Stadtteilbüros, Linux User Initiativen etc. sozial Schwachen zugänglich gemacht werden könnten.
100% ACK
Ein aktueller Lenovo T480/490 mit 16 GB RAM und 250 GB NVME kostet gerade ca 200,- netto.
In der Familie nutzt die 10jährige ohne Probleme ein fast gleich altes Notebook, wo ich lediglich noch RAM und für knapp 30,- EUR einen frischen Akku nachgekauft habe. Ein aktuelles Windows bekommst Du da nicht mehr zum Laufen, wohl aber ein normales Gnome mit Firefox, Thunderbird, Libreoffice und unsere Familien-Nextcloud.
Auf T480/T490 läuft problemlos Win 10 und Win 11, Treiber offiziell von Lenovo.
Beispiel: https://pcsupport.lenovo.com/de/de/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/downloads/driver-list
Die Sicherheitslücke im Shim-Bootloader war CVE-2023-40547.
Dadurch kann ein Angreifer remote per HTTP (!) Code einschleusen und secure-Boot umgehen.
Allerdings kann der Angreifer diese Sicherheitslücke nur dann ausnutzen, wenn SHIM per http von einem Server die zu bootenden Dateien nachlädt (also Man-in-the-Middle-Angreifer).
Wer bootet aber per HTTP von einem Server sein OS?
Normalerweise lädt SHIM lokal von der aktuellen Festplatte den GRUB-Bootloader nach und dabei passiert gar nichts, was ein Angreifer ausnutzen könnte. Der GRUB wiederum lädt Linux oder Windows, je nachdem, was der User möchte.
Trotzdem ist es richtig, dass auch so eine Sicherheitslücke im SHIM gepatcht wird und dass per UEFI-Datenbank die alten ungepatchten SHIM deaktiviert werden.
Publiziert wurde diese Lücke seit dem 23.Januar 2024.
Entdeckt wurde die Lücke aber bereits im Jahr 2023, weil 2023 im CVE steht.
Red Hat hat damals als ersten funktionierenden Schutz empfohlen, einfach Netzwerk-Boot abzuschalten, wenn man das nicht braucht.
Secure-Boot kann dann aktiv bleiben.
nvd[.]nist[.]gov/vuln/detail/CVE-2023-40547
cve[.]mitre[.]org/cgi-bin/cvename.cgi?name=CVE-2023-40547
www[.]openwall[.]com/lists/oss-security/2024/01/26/1
access[.]redhat[.]com/security/cve/CVE-2023-40547
www[.]suse[.]com/security/cve/CVE-2023-40547.html
> Wer bootet aber per HTTP von einem Server sein OS?
Oh mir fallen auf Anhieb IoT ein. Bei VOIP-Telefonen der Marke Alcatel bin ich mir recht sicher, dass die Ihre Images von der lokalen TK-Anlage ziehen. So wie ich diese kennen gelernt habe und so manche Telefonbauern einschätze bestimmt alles unverschlüsselt.
Wie heißt der Spruch? Das S in IoT steht für Security…
Normalerweise wird beim Einschalten das UEFI gebootet und das UEFI schaut dann in seiner DBX-Datenbank nach, was alles gesperrt ist. Falls es keinen Sperrvermerkt zum aktuell installierten SHIM in dieser Datenbank gibt, dann springt das UEFI zum SHIM und übergibt ihm die Kontrolle, so dass der SHIM dann weiter nachladen kann, entweder von einem Server oder lokal den GRUB und der GRUB dann das OS laden kann.
Diese DBX-Datenbank wurde aber zu klein und deshalb hat Microsoft dieses SBAT erfunden und im UEFI per Update implementiert (ohne das prominent zu kommunizieren oder zu warnen).
In der neuen SBAT-Datenbank stehen jetzt mehr Sperrvermerke für fehlerhafte alte SHIM-Loader drin und deswegen übergibt das UEFI nicht mehr die Kontrolle an diese "defekte" SHIM-Loader.
Der Computer bootet dann nicht mehr, solange SHIM nicht upgedatet wird auf eine Version, deren Signatur nicht in der SBAT-Sperrlisten-Datenbank drin steht oder bis secure-boot abgeschaltet wird.
Offenbar wurde Microsoft die Kompetenz-Kompetenz (Erlaubnis zur Selbstermächtigung) verliehen, jedes UEFI umzuprogrammieren.
Wer weiß, was die da sonst noch so alles einbauen und umschreiben?
>>> Wer weiß, was die da sonst noch so alles einbauen und umschreiben? <<<
Unter Vorbehalt, nach bestem Wissen und Gewissen: Aus (1): "The firmware boot loaders boot the UEFI environment and hands over control to UEFI applications written by the SoC vendor, Microsoft, and OEMs. These applications can utilize UEFI drivers and services." Im Klartext: Im UEFI sind Windows Treiber eingebaut, die u. a. der Hardwarehersteller dort platzierte. Notabene: Bis dahin ist noch keine von der Hard Disk stammende Windows Komponente gestartet, aber – wie ausgeführt – es laufen bereits im UEFI hinterlegte Windows-Treiber! Einschlägiges Lesefutter für Masochisten s. (2).
S. a. (3) PDF-S. 132, wo beschrieben wird, wie man sich in der UEFI Shell diese Treiber auflisten lassen kann; Zitat: "[Kommando] drivers … Displays a list of information for drivers that follow the UEFI Driver Model in the UEFI environment."
(1) https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi
(2) https://uefi.org/specs/UEFI/2.10/11_Protocols_UEFI_Driver_Model.html
(3) https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf
Berichtigung zur Aussage von Microsoft: auf meinem Hauptsystem läuft Windows 11 24H2. Und ja, auch diese Version war davon betroffen. Jetzt nach dem "Patch" von Microsoft läuft Beides, also Windows 11 24H2 und Linux Mint 20.3 wieder mit aktiviertem SecureBoot. Was will man mehr?
Im Übrigen: auf allen meinen PC´s gibt es keinen LAN Boot, also besteht auch von daher keine Gefahr. Microsoft war das aber egal. Sie ham es eben "verkackt"!
Mittels bootfähigen Medium und chroot ->
https://de.linux-console.net/?p=12026
sollte es auch möglich sein, nicht mehr bootbare UNIX/LINUX-Derivate wieder zum Funktionieren zu bringen, sollte man der oben beschriebenen "Real-Satire" ausgesetzt sein – UNIX hat hier doch so seine Vorteile.
Oder einfach SECURE BOOT abschalten und abgeschaltet lassen!
oder Windows löschen und ein besseres Leben. führen
Anmerkung zu KB5041585: auf einigen Rechnern (u.a. DELL Optiplex Reihe) kann es passieren, dass die Aktionen in Linux nach Deaktivieren von Secure Boot (sudo mokutil –set-sbat-policy delete) keinerlei Wirkung zeigt. Der Befehl "mokutil –list-sbat-revocations" listet dann SBAT wieder unverändert mit Stand von 2024. Auf solchen Rechnern muss man zunächst unter Windows das KB5041585 über "Windows Update > Updateverlauf > Updates deinstallieren". Dann sofort vor einem Neustart den von Microsoft empfohlenen Registry Patch (reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD) anwenden. Nachdem Windows die Deinstallation abgeschlossen hat ist die SBAT Datenbank wieder auf dem Stand von 2022 und man kann Secure Boot wieder aktivieren. Die erneute Installation von KB5041585 wird dann wegen des vorher aktivierten Registry Patches erheblich länger dauern, da eine Aktualisierung der SBAT Datenbank dann nicht durchführbar ist. An dieser Stelle ein Tipp: GEDULD! ;-)
'Es ist die vornehmere Umschreibung von "wir haben es mal wieder in bewährter Weise kolossal verkackt".'
Das muss Absicht sein. So dumm können die nicht sein. Die sollten das Windows Logo durch das Bild eines Teufels ersetzen.
Das Logo gehört doch schon zu BSD-Unix.
ich nutze zwei physische SSD anstatt dual Boot auf einer SSD.
Dabei ist jede platte für sich unabhängig und durch Verschlüsselung auch für das andere system nicht einsehbar (bitlocker sowie zfs unter ubuntu).
Wer keine Lust auf zwei physische SSD hat, kann diese ja seit Intel Gen 11
Prozessoren auch als virtuelle SSD im BIOS mittel irst teilen.
in meinem Fall habe ich ein Notebook durch einen Kunden gestellt bekommen und habe meine private SSD dazu gebaut.
Mittels BIOS Boot screen kann ich die Systeme booten.
wenn ich mein "privates" Linux gerät dann mal während der Arbeitszeit brauche, fahre ich es statt über den BIOS Bootmanager einfach als VM im hyper V hoch .
Dadurch blieb mir der ganze Ärger und die Aufregung erspart.
https://discourse.ubuntu.com/t/sbat-self-check-failed-mitigating-the-impact-of-shim-15-7-revocation-on-the-ubuntu-boot-process-for-devices-running-windows/47378
How to mitigate this change on existing Ubuntu installations
For existing Ubuntu installations that are experiencing issues it is possible to use the following workarounds before we release the new ISOs:
Ubuntu 20.04 LTS and above:
– Disable secure boot in the device BIOS settings.
– [optional] Install the system, if you don't yet have an install.
– Boot into Ubuntu and then, depending on release version:
– 24.04: You are good to go, the installed system is fine as the installed system has the 15.8 shim.
– 20.04/22.04: Prior to August 29th the patch is available in the proposed pocket. After August 29th the patch will become generally available and users will simply need to update their system to upgrade to the new shim using the following command: sudo apt update && sudo apt upgrade shim-signed.
– Boot Ubuntu a second time (with secure boot still disabled), this will cause the shim to reset the SBAT.
– Reboot into the BIOS and re-enable secure boot.
Aktueller Stand von heute: bei meiner Linux Mint 20.03 Version wurden gestern zwei Aktualisierungen eingespielt: SHIM und SHIM-Secure. Beide vom Stand 15.08. Nach etwas Recherche wurde mir klar, dass dies die von Microsoft angekündigten aktuellen SBAT Datenbanken für Secure Boot von 2024 sind. Man kann dann also in Windows 11 das Update KB5041587 wieder deinstallieren, den von Microsoft vorgeschlagenen Schalter zur Verhinderung der Aktualisierung von SBAT (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT ->OptOut) wieder entfernen, den PC neu starten und dann besagtes Update erneut installieren. Und Secure Boot läuft dann mit Linux und Windows 11 wieder.
Woran nun die ganze Sache lag vermute ich nur: Debian hatte die aktuelle SHIM Version ja bereits im Mai 2024 ausgerollt. Aber bis all die auf Debian basierten Versionen (Ubuntu, Mint u.a.) das dann übernommen haben hat wohl eine Zeit gedauert. Die Urlaubszeit kam hinzu und Microsoft nahm an, dass das alles gut geht, weil Debian ja schon ausgerollt hatte. War aber nicht so, weil es wohl einfach an der mangelnden Kommunikation lag. Und eben an der Urlaubszeit. Oder weil Entwickler bei Ubuntu bzw. Mint eventuell das alles nicht so eilig sahen. Sei es drum. Nun geht alles hoffentlich wieder bis zum neuesten Patch aus dem Hause Winzigweich.
Happy patchen auch weiterhin! ;-)