[English]Nutzer, die Windows und Linux über Secure Boot auf Rechnern verwenden, dürften seit dem 13. August 2024 ein Problem haben. Microsoft hat mit dem August 2024 Patchday etwas am Boot-Prozess geändert und Boot-Einträge von DBX auf Secure Boot Advanced Targeting (SBAT) umgestellt. Als Folge starten Linux-Installationen auf den betreffenden Systemen nicht mehr im Secure Boot-Modus. Die bedeutet imho, den Secure Boot-Modus abschalten und auf aktualisierte Linux-Distributionen warten.
Anzeige
SBAT durch August 2024-Updates
Ich habe es nur am Rande wahrgenommen, Microsoft hat bei den Updates für Windows im August 2024 Secure Boot Advanced Targeting (SBAT) für alle unterstützten Windows Versionen eingeführt. 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.
Diese Updates führen Secure Boot Advanced Targeting (SBAT) auf Windows-Systemen ein. Ziel ist es, zu verhindern, dass anfällige Linux EFI (Shim-Bootloader) ausgeführt werden. Microsoft schreibt dabei: "Dieses SBAT-Update gilt nicht für Systeme, die Windows und Linux im Dual-Boot-Modus ausführen" und warnt gleichzeitig: "Nach der Anwendung des SBAT-Updates lassen sich ältere Linux-ISO-Images möglicherweise nicht mehr booten. Wenden Sie sich in diesem Fall an Ihren Linux-Anbieter, um ein aktualisiertes ISO-Image zu erhalten."
Lesermeldungen über Boot-Probleme
In diesem Kommentar fragte FFred nach Informationen nach den Folgen der Einführung von Secure Boot Advanced Targeting (SBAT), und Bolko verwies auf einen Beitrag bei heise, wo Probleme mit dem Booten von Linux-Systemen thematisiert wurden. Leser Paul meldete sich in diesem Kommentar und berichtete von Boot-Problemen.
Sowas habe ich heute NACH dem Augustupdate KB5041580 (W10) mit meinem Ventoy USB-Stick (UEFI, Version 1.0.98) festgestellt, der VOR diesem Update n0ch bei eingeschaltetem Secure-Boot funktionierte.
Beim Bootversuch vom USB-Stick kam eine Fehlermeldung, die ich so zum ersten mal sah:
———————–
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
———————–
Die Meldung erschien für gut 5 Sekunden auf schwarzem Hintergrund und dann schaltete sich der Rechner aus.
Nach dem Ausschalten von Secure-Boot ging es dann.
Da hat ihm das Windowsupdate wohl seinen Sicherheitsschlüssel aus dem BIOS weggeputzt, vermute ich.
Blog-Leser Peter hat sich zum 18. August 2024 mit diesem Kommentar gemeldet und schreibt, dass SBAT nach dem August 2024-Update – im Gegensatz zu obiger Microsoft-Aussage – auch im Dual Boot-Betrieb ausgeführt werde. Auch er erhielt die Meldung "Verifying shim SBAT data failed: Security Policy Violation" und der Rechner schaltet sich aus. Einzige Lösung ist, Secure Boot für die Maschine abzuschalten.
Anzeige
Noch eine Meldung mit Workaround
Ich hatte bereits einen Blog-Beitrag zum Thema auf dem Schirm, als noch die Mail von Blog-Leser Tibor eintraf, der nach Installation des Windows 11-Updates beim Start des Systems mit der Fehlermeldung:
Verifying shim SBAT data failed: Security Policy Validation
beglückt wurde. Der betreffende Rechner hat sich nach Sekunden abgeschaltet. Er betreibt auf seinem Rechner Linux Mint 20.3 und Windows 11 im Dual Boot. Als er dann zum Thema recherchierte, kam er dem oben skizzierten Grund auf die Spur und schrieb:
Recherchen zu diesem Begriff machten mich völlig fassungslos: Microsoft hat in meinem UEFI BIOS mit aktiviertem Secure Boot
und TPM herumgepfuscht, sodass ich nun nur noch Windows 11 mit aktiviertem Secure Boot starten konnte.
Ohne Secure Boot ging beides!
Nach langem Suchen hat er zwei Lösungen in Foren gefunden und diese dann für sich kombiniert. Das hat ihm letztendlich (in seinem Fall) geholfen:
1. Disable Secure Boot
2. Boot linux mint 22 from Boot stick
3. open a terminal
4. Delete the SBAT policy with:
sudo mokutil –set-sbat-policy delete
sudo mokutil –list-sbat-revocations (sollte nur 1 eintrag sein)
5. Reboot and re-enable secure boot in your BIOS.
6. Reboot your PC and log back into Ubuntu to update the SBAT policy with
sudo mokutil –set-sbat-policy latest
Der Leser schrieb dazu noch, dass es Ankündigungen von Microsoft dazu bereits gab. Aber niemand hatte wohl auf dem Radar, dass sich das so heftig auswirkt. Der Leser merkte noch an, dass bei einigen älteren PC´s mit 3. Generation Intel-CPU noch nicht mal die obige Fehlermeldung angezeigt wird. Stattdessen verabschiedet sich das Gerät in eine Bootschleife. Er sieht die Linux Community teilweise in der Schuld, da dort immer wieder zum Abschalten von Secure Boot geraten werde.
Alpträume wahr geworden
Wenn ich es richtig in Erinnerung habe, warnten Entwickler aus der Linux-Community bereits vor mehr als 14 Jahren, dass Microsofts Secure Boot der Kill-Switch sei, um Linux auf Windows-Rechnern still zu legen. Aus der Windows-Ecke hieß es immer, dass die Linux-Entwickler ja nur einen gültigen Secure Boot-Lader bereitstellen müssten. In Folge wurden solche Lader für Linux entwickelt, so dass Systeme mit Secure Boot sowohl Windows als auch Linux booten konnten.
Nun ist also ein solches Szenario wahr geworden – heise hat es hier beschrieben. Bisher wurden die benötigten Signaturen zum Booten in der DBX-Datenbank des BIOS/UEFI abgelegt. Heise schreibt, dass diese Datenbank bei einigen BIOS-Systemen zu klein für viele Signatur-Einträge sei. Mit den August 2024-Updates wurde nun von Microsoft das von der Open-Source-Community entwickelte Secure Boot Advanced Targeting (SBAT) nachgerüstet – eine Erklärung zum UEFI shim-Boot-Loader findet sich hier.
Mit den August 2024-Updates hat Microsoft begonnen, die in der UEFI DBX-Datenbank hinterlegten Keys für die Boot-Lader zu sperren. Nun seien es die Linux-Boot-Loader Shim und Grub, die einen Systemstart verweigern, weil die Integrität des Secure Boot nicht mehr gewährleistet ist, erklärt heise. Auf Hacker News gibt es hier noch einen Erklärungsversuch.
Momentan ist unklar, welche Linux-Distributionen betroffen sind. Aktuell heißt es zur Lösung aber wohl "Secure Boot abschalten und auf eine aktualisierte Linux-Distribution warten", um das Problem zu lösen.
Alles Probleme, die der Nutzer nicht braucht. Und ob die Systeme durch Secure Boot und obige Schlenker wirklich sicherer werden, darf bezweifelt werden.
Ergänzung: Microsoft hat das Problem eingestanden – näheres habe ich im Beitrag Microsoft äußert sich zu per Windows August 2024-Update lahm gelegtem Linux-Boot zusammengetragen.
Ähnliche Artikel:
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (13. August 2024)
Patchday: Windows 11/Server 2022-Updates (13. August 2024)
Windows Server 2012 / R2 und Windows 7 (13. August 2024)
Anzeige
Die Behauptung von Microsoft, Zitat "Dieses SBAT-Update gilt nicht für Systeme, die Windows und Linux im Dual-Boot-Modus ausführen" ist durch die Probleme, die viele User nun beobachten, widerlegt. Ob darin von Seiten Microsoft Absicht steckt weiß wohl nur Microsoft allein. Und in den UEFI BIOS Einstellungen steht nach wie vor NUR Microsoft als sicheres Betriebssystem. Warum wohl?
Der Witz bei all dem: durch das gezwungenermaßen Abschalten von SecureBoot wird so ein System wieder ein Stück weit unsicherer. Dabei ist NICHT Linux das Problem sondern Windows mit seinen vielen Sicherheitslücken!
Verantwortlich für diese "Linux Sperre" ist übrigens das Kumulative Update für Windows 11 Version 24H2 für x64-basierte Systeme (KB5041571), welches man übrigens über "Windows Update > Updateverlauf > Updates deinstallieren" auch wieder entfernen kann. Allerdings beim nächsten Suchen nach Updates wird es wieder installiert. Und man hat dann wieder daselbe Problem beim Booten: Verifying shim SBAT data failed: Security Policy Validation. Ich kann nur hoffen, dass die Linux Community hier in nächster Zeit eine Lösung findet.
Hinweis an Günter Born: Bei dem Befehl "sudo mokutil –set-sbat-policy delete" müssen nach mokutil ein Leerzeichen und dann ZWEI Minuszeichen sein. Evtl. einen anderen Zeichensatz verwenden.
Leider habe ich inzwischen feststellen müssen, dass mein "Workaround" über den Boot einer neueren Linux Version nicht mehr funktioniert. Microsoft hat da wohl schnell dazu gelernt. DANKE liebe Winzigweich Softies! Secure Boot bleibt jetzt aus. Eventuell findet sich ja irgendwann noch eine bessere Lösung.
Meine hier am 19. August gemachte Meldung kann ich nun glücklicherweise korrigieren: der Workaround HAT wieder funktioniert. Nur ist das eben eine Art "Kochrezept". Manche UEFI basierte Systeme spielen da mit, andere nicht. In meinem Fall hatte ich vergessen, im UEFI BIOS die Option Secure Boot Mode auf [Custom] zu setzen. Erst dann funktioniert der o.g. Workaround. Doch das gilt leider nicht für alle Systeme. Trotzdem viel Glück!
Herr Born, nicht das Windows-Update legt etwas lahm, sondern "die Linux-Boot-Loader Shim und Grub, die einen Systemstart verweigern, weil die Integrität des Secure Boot nicht mehr gewährleistet ist." Das wird auf Heise ausführlich erklärt und ist ein Versäumnis der Linux-Distributionen, dass sie jahrelang nicht auf aktuelle Boot-Loader upgedatet haben.
Fazit: Die Linux(!!)-Bootloader verweigern den Systemstart, da Windows nun eine aktuelle Liste aller veraltetet/unsicheren Bootloader mitliefert, die eigentlich per BIOS kommen sollten, dort aber oft keinen Platz finden bzw. es keine BIOS-Updates mehr gibt.
Wenn Bankomaten alte Karten nicht mehr akzeptieren, die unsicher sind, dann sind auch nicht die Bankomaten schuld, sondern die Banken, die die Karten nie getauscht haben.
ich korrigiere mal dein Fazit: wer Secure Boot nutzt, ist der MS Willkür unterworfen und wird über kurz oder lang am A… sein.
Viel Spaß dabei
Ich wiederum habe gelesen*), dass einfach seitens Microsoft per dekretum "alt" definiert wurde, weil es einfach zu viele unsichere Bootloader gab, die in der Liste keine Platz mehr fanden – die meisten davon wirklich "alt". Aber eben auch die aktuell noch ausgerollten Bootloader, die vielleicht doch nicht unsicher sind, aber für Microsoft alt genug.
Mit der Definition "alles älter als… ist per se unsicher und damit Bleiberecht verwirkt" hat sich MS, das ja m.W. fremde Bootloader signieren muss (Abhängigkeit), Platz freigeschaufelt, da nun ein Eintrag reich – der von Windows.
*) Citation needed – irgendwo in einem der Threads von Heise.
Ich habe nur ein System, von dem ich boote – Linux, und Windows nur noch in der VM. Kann ich machen, da ich kein Zocker bin; ich verstehe auch, dass das ein Grund sein kann, Windows immer noch nativ zu nutzen.
Das ist leider immer noch ein altmodisches denken, aus der Windoofwelt. Dank Valve bzw Proton und dem Vorgänger Wine, ist auch Gaming auf Linux ohne größere Probleme möglich. Ich selbst zocke seit 2 Jahren nur noch auf dem Linux PC und habe wirklich sehr selten ein Spiel, das gar nicht funktioniert, oder unspielbar ist. Gut 90% der Games funktionieren ohne Probleme.
@Joachim.
Nein, das ist eine beliebte Ausrede, wenn man die Schuld an etwas auf jemanden anderen schieben will. Wer bitte hat M$ gestattet, auf meinen PC etwas an dem Inhalt der Hardware zu verändern?
Wenn M$ morgen etwas am BIOS verändert, das den Start von nVidia Grafikkarten verhindert, weil sie das Logo von nVidia nicht schön finden ist es dann auch die Schuld von nVidia, weil sie kein "schönes" Logo haben?
Die Firma, die das mit Abstand unsicherste OS produziert, deren Mailserver so buggy und unsicher ist, dass er sofort überall runtergefahren werden müsste und deren monatliche Updates regelmäßig mehr auf den gepatchten Systemen lahmlegen als sie fixen erlaubt sich festzulegen, welches OS auf meinem (meinem !!!!) PC starten darf.
Diesen shice kannste in keinem Holywoodfilm einbauen, die Zuschauer würden schreiend das Kino verlassen.
Der Vergleich mit den Bankautomaten ist so absurd, da musste ich erst mal ne Stunde gepflegt lachen/weinen (im Wechsel).
Es ist MEIN PC, MEINER! Auf diesem PC entscheide einzig und allein ich, welches OS hier bootet. Und wenn es eine Eigenentwicklung unseres Praktikanten ist und ich das booten lassen will dann ist das so. Ich will mir das nicht erst von M$ absegnen lassen müssen. Der Geldautomat ist (wahrscheinlich) Eigentum der Bank. Die kann damit machen was sie will.
Da muss man sich ja schon zuerst die Frage stellen, warum Microsoft quasi die Hoheit über die Bootloader hat. Und danach, ob Grub und Shim nicht genau richtig reagieren den Boot zu verweigern, da das System ja offensichtlich modifiziert wurde.
Ich persönlich finde die von Microsoft zu signierenden Bootloader einfach nur ein Ärgernis, dass die Sicherheit auch kaum erhöht.
Zu dem Zertifikatsablauf kommt ja dazu, dass Microsoft anscheined sehr freigiebig mit Signaturen war.
MS hat es laut Heise übrigens mal wieder völlig vergeigt, nicht Linux.
Das kann man auch anders sehen: An Grub und Shim hat sich ja nichts geändert, Microsoft hat die Schlüssel zum PC ausgetauscht
Vielleicht merken so langsam auch die Letzten, dass die PC Hardware nicht mehr ihnen gehört…
Da stellt sich mir allerdings ernsthaft die Frage: Darf Microsoft so einfach am BIOS meines Rechners herum manipulieren? Auch von der rechtlichen Seite her sollte man sich diese Frage mal stellen. Der PC gehört ja immer noch mir. Oder?
Mit an Sicherheit grenzender Wahrscheinlichkeit: JA, denn Sie haben per EULA zugestimmt.
Irgendeine verschwommene Formulierung darin räumt MS recht sicher jenes Recht ein.
StGB, § 303b, Computersabotage: https://www.gesetze-im-internet.de/stgb/__303b.html
STRAFGESETZBUCH: deutsche Gesetzgebung
MICROSOFT: (US)amerikanisches Unternehmen
Du verstehst hoffentlich den Unterschied!?!
Das StGB gilt selbstredend auf für von nicht-deutschen Entitäten (w/m/d) auf deutschem Boden begangene Straftaten.
#Servicetweet
Ich habe mich mal an einer rechtlichen Bewertung getraut. Maßgeblich ist hier das BGB und nicht das StGB
https://blog.jakobs.systems/blog/20240820-secure-boot-suendenfall/
Strafbarkeit und zivilrechtliche Haftung schliesen sich nicht aus.
Davon ab: Ich ging ausschliesslich auf die Falschbehauptung von @(another)Anonymous ein, machte keine eigene rechtliche (Be-)Wertung (auch nicht zur von @Anonymous angedeuteten Strafbarkeit).
Solche Dinge passieren regelmäßig, wenn das Haltbarkeitsdatum von Schlüsseln abläuft. Irgendwie kommt das dann immer ganz unerwartet, obwohl man sich schon Jahre vorher eine Erinnerung eintragen könnte.
Acht Jahre? Viele Zertifizierungsstellen stellen Zertifikate nur noch für ein Jahr + ein paar Tage Karenz aus. Hier sind Kalendereinträge unerläßlich.
Laut Heise: "Bereits auf Festplatte oder SSD installierte Linux-Systeme, auf denen die aktuellen Updates eingespielt wurden, booten in jedem Fall auch weiterhin."
Würde der Erfahrung von "Tibor" widersprechen. Bin gespannt, was bei mir (vor etwa 5 Jahren installierter Dual-Boot) passiert, wenn ich in einer Woche das bis dahin hoffentlich ausreichend abgehangene Win10-Update installiere.
Unabhängig davon verstehe ich nach wie vor den Sinn von Secure Boot nicht, wenn es von der Betriebssystem-Ebene aus, also z.B. durch Windows-Updates, möglich ist, zu beeinflussen, was sich booten lässt und was nicht. Ich weiss schon, ist alles signiert und so, und es ist ja auch noch nie vorgekommen, dass irgendjemandem ein Schlüssel abhanden gekommen ist…
Die Berichterstattung ist ja vollkommen daneben.
Wie sollte Microsoft hier anders vorgehen? Die Sicherheit Lücken alle offen lassen?
Warum schalten die Leute Secure Boot nicht aus wenn sie es nicht wollen?
Warum kaufen die Leute Mainboards/PCs die Secure Boot nicht ausschalten können?
Sind es nicht die Linux User die hier immer davon reden wie sicher ihr System ist.. bis auf den Fact dass Linux aktuell Secure Boot nicht kann. Und die meisten nicht Mal verstehen warum Secure Boot gebraucht wird.
Du verkürzt hier unzulässigerweise und wirfst einiges durcheinander.
Secure Boot ist kein Sicherheitsmerkmal (mehr) da es mehrfach überwunden und die Implementierungen bei Motherboard Herstellern seit Anfang an fehlerhaft waren. Bestenfalls wiegt es einen in trügerischer Sicherheit.
Da aber bei Lieschen Müller und Waldi Admin auf neuen Windows Rechnern Secure-Boot meist by Default aktiv ist, haut Microsoft mit besagten Updates jede Chance raus diese Systeme fremd zu booten. Das beginnt bei dem Versuch, ein Image für Backups zu ziehen und hört bei der erheblichen Wertminderung von Hardware auf, wenn diese einem Gebrauchtmarkt nach 3 Jahren Leasingdauer überführt wird. Eine Hardware, wo sich by Default kein anderes System jenseits Microsoft installieren lässt, ist im Wert gemindert.
Secure Boot wird z.B. von Debian seit Version 10 (in 2019 veröffentlicht) unterstützt.
>> Wie sollte Microsoft hier anders vorgehen?
Die Grundfrage ist erst einmal, wieso Microsoft überhaupt auf die Idee kommen kann, am UEFI/BIOS meines PCs etwas zu ändern. Schlimm genug, dass das technisch überhaupt möglich ist (ich wiederhole mich).
Aber tun wir mal so, als ob das in Ordnung wäre, und Microsoft hier eine Sicherheitsaufgabe für die Allgemeinheit wahrnähme. Dann sollte Microsoft:
(a) Änderungen am UEFI/BIOS nicht in Windows-Updates verstecken, weil das mit Windows absolut nichts zu tun hat.
(b) Dafür sorgen, dass Bootlader, die nach allem was wir wissen sicher sind, nicht durch die Updates beeinträchtigt werden.
(c) Jedem Rechner-Besitzer freistellen, ob er diese Updates installieren möchte, und für den Fall der Fälle eine einfache Rollback-Möglichkeit vorsehen.
Das ist doch nicht so schwierig, oder?
P.S.: Auch mein Linux Mint kann Secure Boot.
Sehr richtig. Die Frage stellt sich mir schon länger, ob es überhaupt rechtlich in einwandfrei ist, wenn MS an meinen UEFI-Einstellungen ungefragt herumwerkelt. Wenn MS unterbinden würde, dass Windows startet, weil irgendwas mit Secure Boot nicht stimmt, okay. Aber mein UEFI zu verfrickeln, das per se nichts mit Windows zu tun hat, das ich auch nicht bei MS erworben habe und das MS nicht gehört oder entwickelt hat…?!?
Ich könnte mir vorstellen, dass dieses Vorgehen sogar rechtlich nicht einwandfrei ist (aber ich bin kein Anwalt oder Jurist).
UEFI, Windows und Linux … "Fluch" oder "Segen" … ?!?!? Immer dies Patcherei und Updaterei … zum Kotzen.
Zum Glück muss ich bei meinem Amiga nur alle 4-5 Jahre mal die BIOS-Batterie CR2032 ersetzen, damit die Echtzeituhr funktioniert.
Compactflash-Speicher + AmigaOS 4.xx … und alles läuft auch ohne Internet und "Updateritis" einwandfrei, stabil und virenfrei. 32bit-CPU @40 MHz (MHz! nicht GHz!) und 12 MB (!!) RAM reichen auch … und das seit ca. 30 Jahren …
(ja, OK, es mussten auch mal ein paar Elkos ersetzt werden … chemische Alterung lässt grüßen)
Bei den Patches geht es um vernetzte Rechner. Wäre der Amiga im Internet, gäbe es auch Updates..
Pffff.. Amiga hatte damals jeder in meinem Umfeld. Ich galt als Exot, weil ich zum deutlich schlechteren Euro-PC griff, der mich zum Arbeiten und Programmieren regelrecht zwang während die anderen rumspielten :-P
Habe mir nach 36 Jahren unlängst einen Traum erfülllt und eine (funktionierende!) 20 MB Festplatte in der Bucht geschossen…. frag besser nicht nach den Preis…
https://blog.jakobs.systems/micro/20240506-schneider-euro-pc-hdd/
Ich hatte einen Fall mit einem GIGABYTE Z690 Gaming X mit Windows 10 22H2 auf einer NVMe und Linux Mint 21.1 Xfce auf einer weiteren. Gebootet wurde Grub als default Boot-System, in dessen Bootmenü Windows ausgewählt werden konnte. Dieser Rechner hat die Umstellung auf SBAT nicht überstanden: "Security Policy Violation".
Die Einstellmöglichkeiten von SecureBoot um UEFI waren "Auto", "Easy" und "Advanced". Ich habe keine Ahnung, was was bewirkt. Ich konnte keinen Unterschied feststellen, und in keiner Einstellung war SecureBoot abgeschaltet.
Ein USB-Stick mit einer Mint 22 Xfce-ISO ließ sich booten, und mit "Boot from local drive" aus dem Bootmenü dieser ISO startete auch das installierte Mint 21.1. Damit stand mir ein Weg offen, zumindest mit einem Upgrade auf Mint 22 das Ganze wieder zum Laufen zu bringen.
Ich habe das Mint 21.1 auf 21.3 upgegradet um den ersten Schritt zu Mint 22 zu vollziehen. Direkt danach, ohne das Mint 21.3 zu starten, habe ich das BIOS upgedatet auf die neueste verfügbare Version vom 07.08.2024. Ich vermute, damit habe ich die Umstellung auf SBAT rückgängig gemacht, wissen tue ich es aber nicht. Jedenfalls läuft das Ganze jetzt wie vorher – Mint 21.3 macht für den Anwender keinen Unterschied. Das Upgrade auf Mint 22 habe ich nicht durchgeführt, meine Tests damit sind noch nicht durch. Als Notlösung bleibt mir das allerdings noch, falls Microsoft im September eine erneute Umstellung auf SBAT vornimmt.
Wolle
Etwas Hintergrundwissen: https://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot
Secure Boot gehört in die Kategorie "Gut gemeint, aber schlecht gemacht". Aus meiner Erfahrung macht es mehr Probleme als es nutzt. Wenn man Compliance-Prüflisten abhaken muss, darf man es leider nicht abschalten.
mir ist keine Norm bekannt, die explizit Secure-Boot vorschreibt… Du?
Das BSI hat dazu z.B. das:
SiSyPHuS Win10: Studie zu Systemaufbau, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10
https://www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS_node.html
Konfigurationsempfehlungen zur Härtung von Windows 10 mit Bordmitteln
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/SiSyPHus/Konfigurationsempfehlungen_zur_Haertung_von_Windows_10.html
PDF:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/SiSyPHus/Konfigurationsempfehlungen_zur_Haertung_von_Windows_10.pdf?__blob=publicationFile&v=3
5.6.5 Sonstiges
Stellen Sie sicher, dass der sichere Start (SecureBoot) aktiviert ist.
Siehste, Studien, Konfigurationsempfehlungen aber eben genau keine explizite Vorgabe oder Norm wie ISO oder TISAX oder VDS 10000.
Ich lasse bei einem TISAX Audits jedes Windows XP durch, wenn es hinreichend isoliert ist.
@Anonymous 18:31 Uhr beschreibt es doch recht gut:
Wer das Geld für einen Audit in die Hand nimmt (…nehmen kann) mag eine Art Versicherungspolice abschliessen, letztlich entscheidet aber ein Gericht (in IT-Sachen oft "nach Gusto", weil sie blutige Laien sind), ob das eine Pflichtverletzung war und die rechtliche Definition ist eben das schwammige "Stand der Technik".
Im Zweifelsfall via "Stand der Technik" pseudoverpflichtend :P
"Waaas, Secure-Boot war nicht eingeschaltet?ß?? Wie konnten Sie nur!!!1!"
Soeben wird auch auf GOLEM das Dual Boot Problem ausführlich geschildert:
https://www.golem.de/news/linux-startet-nicht-microsoft-patcht-dual-boot-systeme-kaputt-2408-188218.html
Interessant ist folgendes Zitat aus der Meldung: "… scheinen selbst Systeme auf Basis eines aktuellen Ubuntu 24.04 betroffen zu sein."
Houston, we HAVE a PROBLEM!
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2#3377msgdesc:
This SBAT update will not be applied to devices where dual booting is detected. On some devices, the dual-boot detection did not detect some customized methods of dual-booting and applied the SBAT value when it should not have been applied.
Microsoft hat es, wie üblich, wieder verkackt. :(
Ein großes DANKESCHÖN für diesen Hinweis (auch an Microsoft!), insbesondere wie man Windows davon abhält, den DualBoot wieder kaputt zu machen. Dieser Hinweis sollte ganz oben erscheinen.
Mein Laptop bootet seit heute nicht mehr, weder in Windows 11 noch in Linux mit der oben bezeichneten Fehlermeldung.
An wen bei Microsoft kann ich mich wenden, dass er meinen Rechner wieder betriebsbereit setzt?
Ich plane außerdem Strafanzeige wegen Computersabotage §303b StGb zu stellen.
(1) Wer eine Datenverarbeitung, die für einen anderen von wesentlicher Bedeutung ist, dadurch erheblich stört, dass er … eine Datenverarbeitungsanlage oder einen Datenträger …unbrauchbar macht.. wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.
Das Problem ist seit Tagen bekannt, warum ist mein Rechner heute davon betroffen?