[Thoronador]

Hallo!

Seit heute Abend kommt auf meinem Laptop (älteres Modell der HP Omen-Reihe) beim Start eine Meldung, die in etwa wie folgt lautet:

Verifying shim SBAT data failed: Security Policy Violation
Something has gone serously wrong

Oder so ähnlich. Genau konnte ich's mir nicht merken, da sich der Laptop kurz nach Einblendung der Meldung abschaltet. Das ist dann auch das Problem, denn damit wird das Gerät praktisch unbrauchbar. Kennt da jemand eine Lösung? Für den Moment habe ich im BIOS einfach Secure Boot deaktiviert, dann kommt diese Meldung nicht und das System startet. Aber das ist ja nicht im Sinne des Erfinders.

Mein Verdacht ist, dass es an einem Update vom Microsoft-Patchday für August liegt, denn der war heute (bzw. inzwischen gestern) und ich habe die Updates installiert. Nach dem Update habe ich noch einen Reboot durchgeführt, da gab es noch keine Probleme. Erst danach ging es los.

Auf dem Laptop läuft ein Windows 10 im Dual Boot mit Ubuntu 20.04 und GRUB als Bootloader, falls das wichtig ist. Mehr Details kann ich auf Nachfrage nachliefern.

[Lookbehind]

Schuss ins Blaue: foobar hat neulich was von Problemen mit dem Key-Speicher bei Secure-Boot berichtet.

[foobar]

SBAT steht für „Secure Boot Advanced Targeting” und ist die von der Open Source Community gewählte Lösung für das Problem, dass UEFI und Secure Boot totaler Mist sind und gerade an sich selbst zu scheitern drohen (Details: siehe dieser Thread).

Du kannst Secure Boot ausgeschaltet lassen, IMHO entgeht dir da nicht viel. Ansonsten musst du mal gucken, ob es Updates gibt, welche du installieren kannst, die das beheben. Irgendwas in deiner Bootkette ist auf der SBAT-Sperrliste gelandet.

EDIT: Zu spät.

[Thorondor]

Das klingt ja so, als wäre das Problem in den Komponenten der Ubuntu-Installation zu suchen. Soweit ich mich erinnern kann, habe ich da aber in den letzten Tagen keine Änderungen / Updates durchgeführt, die mit dem Bootvorgang in Zusammenhang stehen. Also müsste das Windows-Update die SBAT-Sperrliste aktualisiert haben, wenn ich das richtig verstehe?

Irgendwas in deiner Bootkette ist auf der SBAT-Sperrliste gelandet.

Wie lässt sich herausfinden, welche Komponente das betrifft?

[foobar]

Das klingt ja so, als wäre das Problem in den Komponenten der Ubuntu-Installation zu suchen. Soweit ich mich erinnern kann, habe ich da aber in den letzten Tagen keine Änderungen / Updates durchgeführt, die mit dem Bootvorgang in Zusammenhang stehen.

Kann ich natürlich von hier aus wenig zu sagen. Evtl. hast du ein Update übersehen. Oder Windows hat irgendwo an den Zertifikaten gespielt, die nun ein anderes Problem triggern. Wer weiß schon, was bei UEFI wirklich unter der Haube alles abläuft? Aber es muss sicher sein, schließlich hat es ja das Wort „Secure” im Namen!

Wie lässt sich herausfinden, welche Komponente das betrifft?

Nicht so trivial. Theoretisch kann man mit

mokutil --list-sbat-revocations

die Sperrliste anzeigen lassen und das dann mit den verwendeten Komponenten vergleichen.

Via

mokutil --set-sbat-policy delete

kann man die Sperrliste auch löschen. Das scheint die empfohlene Methode für solche Probleme zu sein: Secure Boot aus, SBAT löschen, alle Updates einspielen (wobei die SBAT auch aktualisiert werden sollte) und rebooten und dann ganz zum Schluss Secure Boot wieder an. Eigene Erfahrungen habe ich natürlich nicht, weil ich Secure Boot gar nicht erst nutze.

Ich weiß jetzt nur nicht, ob das mokutil im alten Ubuntu 20.04 das alles bereits unterstützt. Eventuell musst du zu was neuerem greifen (ggf. via Rettungssystem).

Vielleicht kann auch ein Upgrade der Distribution an sich helfen. Das Problem scheint primär alte Distris mit Langzeitsupport zu betreffen. Lange läuft der normale Support für 20.04 ja eh nicht mehr (8 Monate). Und wenn du kein Pro-Abo hast, aber Pakete aus den Uni- oder Multiverse-Repos einsetzt, dann kann es gut sein, dass für diese eh der Support schon lange ausgelaufen ist. Was ggf. ein größeres Sicherheitsproblem sein kann als ein deaktiviertes Secure Boot.

[Nobbi Habogs]

Secure Boot?!

WO IST DAS WEIHWASSER

[Homerclon]

Schuld ist doch Microsoft (welch Überraschung ...)
MS wollte eine Sicherheitslücke im GRUB-Bootloader schließen, das Update hätte eigentlich bei Systeme mit Dual-Boot gar nicht ausgespielt werden dürfen, wurde er dann aber doch.

https://winfuture.de/news,144650.html


Von MS gibts (vorerst) keine Hilfe, aber den passenden Workaround hat Foobar bereits gepostet.

[Thoronador]

Kann ich natürlich von hier aus wenig zu sagen. Evtl. hast du ein Update übersehen.

Sowohl bei Windows als auch bei Linux sind alle verfügbaren Updates, die über die Updatefunktion von Windows bzw. die offiziellen Paketquellen von Ubuntu verfügbar sind, bereits installiert.

Oder Windows hat irgendwo an den Zertifikaten gespielt, die nun ein anderes Problem triggern. Wer weiß schon, was bei UEFI wirklich unter der Haube alles abläuft? Aber es muss sicher sein, schließlich hat es ja das Wort „Secure” im Namen!

Oh ja. Genau sowie TPM (Trusted Platform Module) auch "trusted" ist.
Nach der Logik könnte ich auch einen "Gebt mir alle euer Geld und ihr werdet reich!"-Investitionsfond eröffnen und fett abkassieren. Steht ja im Namen, also muss es stimmen.

Nicht so trivial. Theoretisch kann man mit

mokutil --list-sbat-revocations

die Sperrliste anzeigen lassen und das dann mit den verwendeten Komponenten vergleichen.

Ausgabe davon ist zur Zeit:

sbat,1,2024010900
shim,4
grub,3
grub.debian,4

Bringt natürlich nicht viel, wenn man nicht weiß, welche SBAT-Versionsnummer die jeweiligen Komponenten gerade haben. Daher macht sich das mit dem Vergleich in der Praxis nicht so gut.

Für den Moment lasse ich Secure Boot daher erstmal deaktiviert.

Vielleicht kann auch ein Upgrade der Distribution an sich helfen. Das Problem scheint primär alte Distris mit Langzeitsupport zu betreffen. Lange läuft der normale Support für 20.04 ja eh nicht mehr (8 Monate). Und wenn du kein Pro-Abo hast, aber Pakete aus den Uni- oder Multiverse-Repos einsetzt, dann kann es gut sein, dass für diese eh der Support schon lange ausgelaufen ist. Was ggf. ein größeres Sicherheitsproblem sein kann als ein deaktiviertes Secure Boot.

2025 läuft auch der Support für Windows 10 aus, wenn auch erst ein halbes Jahr später. Bis dahin ist aber geplant, ein neues Gerät mit neuer(er) Software zu haben. Das Update auf Ubuntu 22.04 oder gar 24.04 habe ich bisher nicht durchgeführt, weil seit Ubuntu 22.04 eines der wichtigsten Pakete - der Browser Firefox (und auch Chromium) - nur noch als Snap und nicht als richtiges Paket verfügbar sind.

Abgesehen davon ist laut diesem heise-Artikel sogar Ubuntu 24.04 betroffen. Dist-Upgrade würde demnach nicht helfen.

Secure Boot?!

WO IST DAS WEIHWASSER

Ja was will man denn machen? Als ich das Gerät neu hatte, war's halt so, das Windows unbedingt Secure Boot haben wollte, und das damalige Ubuntu 16.04 (oder 18.04?) kam nicht damit zurecht, wenn man beim Dual Boot ein System mit Secure Boot startet (Windows) und das andere (Ubuntu) nicht. Da hätte man vor dem Booten jeweils ins BIOS gehen und Secure Boot je nach gewünschtem System entweder an- oder abschalten müssen. Das ist dann halt einfach zu viel Aufwand, potentiell vor jedem Start erst einmal BIOS-Einstellungen zu ändern.

Schuld ist doch Microsoft (welch Überraschung ...)
MS wollte eine Sicherheitslücke im GRUB-Bootloader schließen, das Update hätte eigentlich bei Systeme mit Dual-Boot gar nicht ausgespielt werden dürfen, wurde er dann aber doch.

https://winfuture.de/news,144650.html


Von MS gibts (vorerst) keine Hilfe, aber den passenden Workaround hat Foobar bereits gepostet.

Ey, diese "Vollprofis" bei Microsoft wieder!
Aber gut, mit dem Angriff Steiners Einsatz von GitHub Copilot wird das ja alles wieder in Ordnung kommen bei Microsoft.

[Nobbi Habogs]

Ja was will man denn machen? Als ich das Gerät neu hatte, war's halt so, das Windows unbedingt Secure Boot haben wollte, und das damalige Ubuntu 16.04 (oder 18.04?) kam nicht damit zurecht, wenn man beim Dual Boot ein System mit Secure Boot startet (Windows) und das andere (Ubuntu) nicht. Da hätte man vor dem Booten jeweils ins BIOS gehen und Secure Boot je nach gewünschtem System entweder an- oder abschalten müssen. Das ist dann halt einfach zu viel Aufwand, potentiell vor jedem Start erst einmal BIOS-Einstellungen zu ändern.

Aber, aber! Wir sind doch für dich da, natürlich einfach im Forum fragen

[Bild: ovGlwDunbenannt.png]

[foobar]

Für den Moment lasse ich Secure Boot daher erstmal deaktiviert.

Gute Wahl.

Als ich das Gerät neu hatte, war's halt so, das Windows unbedingt Secure Boot haben wollte

AFAIK verlangt Windows 11 nur, dass die Firmware Secure Boot kann (also man bspw. kein Legacy Boot/MBR mehr nutzt). Es muss nicht wirklich zwingend aktiv sein. Das war IIRC auch schon immer so.

Und Windows 10 ist eh egal, wie du bootest. Deshalb musste es ja weg, obwohl es mal das letzte Windows sein sollte.

[jabu]

Aber, aber! Wir sind doch für dich da, natürlich einfach im Forum fragen

[Bild: ovGlwDunbenannt.png]

Soso, jetzt lässt sich Windows also nicht mal mehr ohne Zusatztool (Rufus) brauchbar installieren.

Und Windows 10 ist eh egal, wie du bootest. Deshalb musste es ja weg, obwohl es mal das letzte Windows sein sollte.

Jetzt dämmert mir, warum Windows 10 dass letzte Windows sein soll.
Dann kann alles danach ja weg bzw. ist es (folglich) das Allerletzte (sagt man doch so, oder mache ich was falsch?).

Dann sind die halt selbst nicht überzeugt, von ihrem Produkt (und raten ab), kann man nichts machen.
Wenigstens sind sie ehrlich.

[Nobbi Habogs]

Soso, jetzt lässt sich Windows also nicht mal mehr ohne Zusatztool (Rufus) brauchbar installieren.

Doch, schon. Aber warum schwer, wenns auch einfach geht?

[jabu]

Doch, schon. Aber warum schwer, wenns auch einfach geht?

Das mit der brauchbaren Installierbarkeit hatte ich anders gemeint (mein Humor dazu scheint wohl erst weiter hinten durch).

Es mag zwar vorteilhaft sein, wenn ein in IT-Angelegenheiten laienhafter Freiberufler seine Kunden-/Klienten-/Patientendaten nun zwangsweise verschlüsselt bekommt oder wenn (z.B. in Hotelzimmern) unbeaufsichtigt gelassene Geräte weniger angreifbar sind, aber wer eher Verfügbarkeit braucht, möchte seine Daten vielleicht lieber nicht mit Bitlocker verschlüsselt haben.

Halten wir mal fest:

• Secure Boot überrascht den Nutzer evtl. irgendwann mit Unstartbarkeit. Viele Leute wüssten sich dann zu helfen, aber längst nicht alle, und wenn es einen im falschen Moment erwischt, kann das u.U. sehr ärgerlich sein, und zwar auch dann, wenn man sich einigermaßen auskennt. Außerdem kann man nicht verlangen, dass Leute bei dem immer umfangreicher werdenden Abhängigkeitengespinst auf dem Laufenden bleiben und zusätzlich auch noch geübt haben, irgendwas unter den UEFI-Settings korrekt einzustellen.
  Windows-Update überraschte bei Windows 8.1 manche Nutzer mit Endlos-Update/Rollbacks, falls Secure Boot aktiviert ist. Das hier ist ein Platzhalter für solches und ähnliches Versagen. Was versagt und wie es versagt, sieht man ja erst, wenn es so weit ist, weswegen es im Fall der Fälle nicht hilft, sich mit den (unbestritten vorhandenen) Verbesserungen bei Windows 10 und 11 zu beruhigen.
• Die Daten sind mit Bitlocker verschlüsselt, der Nutzer kann seine Daten bei kaputter Hardware oder nach einem Update-Fehler nicht entschlüsseln, wenn nicht glückt, was MS dafür vorgesehen hat (fragile Abhängigkeiten!).
• Windows wird (im Normalfall) nicht mehr richtig heruntergefahren, sodass das Dateisystem inkonsistent sein könnte, was zwar eher eine Kleinigkeit ist, aber es sollte nicht unerwähnt bleiben.

Alle drei Punkte sind technisch unnötig und oft gegen die Interessen des Nutzers, aber werden ihm trotzdem standardmäßig aufgezwungen! Was man im Nachhinein noch ändern kann, ist zwar gut und schön, aber oft unterbleibt das.

Das Abhängigkeitengespinst wird doch immer weiter gesponnen. Einerseits gibt es bei IT-Systemen wie auch im Papierbüro Datensicherheit als Anforderung, andererseits Verfügbarkeit. Beides befindet sich oft im Zielkonflikt zueinander. Doch es wird, obwohl es falsch ist, immer wieder suggeriert, man könne einfach die eine Form von "Sicherheit" erhöhen, und dann hätte man automatisch per Saldo hinzugewonnen.

Zum Beispiel nehmen viele Leute ihre Hardware nur äußerst selten außer Haus mit und hüten sie dann wie ihre Augäpfel. Sie muss einfach funktionieren, z.B. wenn der Auftraggeber nicht wartet. Aber ja, man kann ein Zweitgerät haben, bei dem Windows-Updates deaktiviert sind, und dann zieht man sich das aus der Cloud, und die anderen Daten holt man sich aus einer anderen Cloud und...

Die Sachen verkomplizieren sich, weswegen ich das Totschlagargument von Backups und Redundanz nicht mehr hören kann. Natürlich sollte man für alles Kritische Vorkehrungen treffen, aber die Lebensrealität ist anders, z.B. indem man immer wieder mit unterschiedlicher Software und unterschiedlichen, teils aufgezwungenen, Prozessen zu tun hat und man eben nicht für alles Kritische Vorkehrungen getroffen haben kann, da es sich eben immer wieder ändern kann, zumal Internet und Cloud-Dienste auch nicht immer verfügbar sind.

In der Realität geht es um Wahrscheinlichkeiten. Je mehr mich jemand bevormundet und mich in seine Anhängigkeitengespinste verwickelt, desto kleiner wird die Wahrscheinlichkeit, dass alles so funktioniert, wie es soll.

Vielleicht erstelle ich, nur mal angenommen, bloß langweilige Spritzgussformen für gewöhnliche Plastikschüsseln, also nichts, was bei Abhandenkommen irgendeinen Fremden interessiert. Aber den Auftraggeber interessiert es umso mehr, dass ich ihm keine Verzögerungen bereite. Oder in einem Szenario kann ich nur genau ein Gerät vorhalten, oder das Zeitgerät streikt gerade, oder es ist zwar das Wichtigste drauf, aber eben doch nicht alles. Irgendeine Lösung ließe sich theoretisch fast immer finden, aber die Realität ist oft zu komplex, und Zeit ist manchmal zu knapp. Sich totzuarbeiten, um für jeden Fall gerüstet zu sein, ist sicher kein Optimum. Das heißt, dass in der Realität Risiken eingegangen werden müssen (sei es auch nur, dass man kein Zweitgerät mitnehmen kann, da man eh schon viel zu schleppen hat).

Deswegen halte ich nichts von Häme, falls Dinge schiefgehen, von wegen, derjenige hätte doch dieses oder jenes tun können (hätte, hätte, Fahrradkette...), zumal Microsoft und andere IT-Firmen einen ja dazu zwingen, immer mehr Vorkehrungen zu treffen, weswegen man selbst doch nicht der Verursacher der verminderten Verfügbarkeit (sondern ein Genötigter) ist. Sie bilden sich ein, ein Teil der, natürlich stets exklusiven und allumfassenden, Lösung zu sein, und wehe du weißt es besser und setzt auf andere, dann machen sie dir das Leben schwer.

Bereits vor 30 Jahren wusste man, wie man die Dinge einfach löst. Nicht nur ich, sondern auch verdammt viele andere Leute wollen es einfach haben. Wenn ich etwas verschlüsseln muss, dann kann ich das mit Lösungen bewirken, die die Verfügbarkeit geringstmöglich reduzieren. Ich spreche hier nicht mal so sehr für mich, sondern mehr für andere, die im Fall der Fälle größere Schwierigkeiten bekommen oder nicht so genau wissen, was sie tun müssen.

Was die üblichen verdächtigen Big-Tech-Firmen der IT-Branche immer wieder fabrizieren, das ist zu erheblichen Teilen das krasse Gegenteil ingenieursmäßiger Arbeitsweise.

Das fängt schon damit an, dass erst einmal das Problem des Kunden verstanden werden muss, wobei normalerweise bereits auffallen sollte, dass die Kunden dergestalt unterschiedliche Probleme haben, dass ein "One-fits-all"-Quirksmurks-Ansatz keine passende Abbildung ist. Die komplett falsche Denkweise zeigt sich auf der Symptomebene z.B. auch dadurch, dass es keinen tauglichen Editor für die Bootkonfiguration gibt oder dass Windows bezüglich seiner Features nicht so sauber modularisiert ist, dass man die einfach an- und ausknipsen (dabei natürlich am Mitstarten hindern) könnte. Es wäre normalerweise machbar, dass eine Anwendung oder ein Tool den Benutzer fragt, ob ein Feature aktiviert werden soll.

Während IT-Firmen in relevanten Bereichen mehr Probleme erzeugen als zu lösen, sind Menschen geboren worden, aufgewachsen und gestorben. Was die IT-Branche so verzapft hat, das müsste eigentlich einmal weggeschmissen und neu gemacht werden, und zwar mit anderen Leuten, die eine andere Einstellung haben. Das mag zwar polemisch überspitzt sein, aber nach zig Jahren ohne Besserung hat man mal die Nase voll. Wir sitzen auf einem stinkenden Haufen an Softwaremüll, und er wird immer größer und schwerfälliger. Microsoft gehört sogar noch zu den Besseren, von CAD/CAE-Software will ich gar nicht anfangen, die ist teils schon in Dysfunktionalität abgerutscht. Unter anderem deswegen meckern nämlich viele Firmen, dass sie ohne schnelles Internet verloren sind. Das ist aber weniger als die halbe Wahrheit, der größere Teil des Problems sitzt in der Software. Die IT hat ein grundsätzliches Problem, bzw. haben nicht die Anbieter das Problem, da die ja immer reicher werden, sondern die in Abhängigkeit gebrachten Nutzer. "Lösungen" können inzwischen fast beliebig schlecht sein, das muss die Anbieter nicht mehr kratzen.

[Nobbi Habogs]

Darum gehts mir nicht, ich widerspreche nur der Behauptung es ginge auch ohne Zusatztools.

[foobar]

jetzt lässt sich Windows also nicht mal mehr ohne Zusatztool (Rufus) brauchbar installieren.

ich widerspreche nur der Behauptung es ginge auch ohne Zusatztools.

Dann seid ihr euch ja einig.

[jabu]

Dann seid ihr euch ja einig.

Jepp (sowas von!).

[Thoronador]

Und Windows 10 ist eh egal, wie du bootest. Deshalb musste es ja weg, obwohl es mal das letzte Windows sein sollte.

Anfangs sah es ja so aus, als ob Microsoft einfach jedes halbe Jahr ein Versionsupdate für Windows 10 herausbringt (z. B. 1703, 1709, 1803, 1809, 19H1, 19H2, 20H1, 20H2, usw.), sodass man für einen Moment den Eindruck hatte, die würden einfach endlos so weitermachen. Aber spätestens als dann Windows 11 rauskam und nach Windows 10 22H2 keine weiteren halbjährlichen Updates mehr kamen, war klar, dass Ende von Windows 10 kommen würde.

Alle drei Punkte sind technisch unnötig und oft gegen die Interessen des Nutzers, aber werden ihm trotzdem standardmäßig aufgezwungen! Was man im Nachhinein noch ändern kann, ist zwar gut und schön, aber oft unterbleibt das.

Ist halt mittlerweile leider fast überall so üblich bei kommerzieller Software. Fängt schon bei so "kleinen" Sachen wie Telemetrie / Datenerfassung an, die für die Funktion der Software unnötig ist, aber der Hersteller will's halt gern haben, also wird es per Vorgabe aktiviert und man muss es manuell abschalten. Irgendwann fällt dann auch die Option zum Deaktiveren dieser "Features" weg. Die Leute kaufen das Zeug halt trotzdem.


Zurück zum eigentlichen Thema:
Heute (oder gestern?) gab's bei Ubuntu 20.04 ein Update für die Pakete shim (von Version 15.7-0ubuntu1 auf Version 15.8-0ubuntu1) und shim-signed (von Version 1.40.9+15.7-0ubuntu1 auf 1.40.10+15.8-0ubuntu1). Damit kann man scheinbar auch wieder mit aktiviertem Secure Boot starten.

Interessant ist, dass die eigentlichen Änderungen für Version 15.8 schon im Januar verfügbar waren, aber im Bugtracker zum Ubuntu-Bug #2051151 kann man sehen, dass sich das bis gestern gezogen hat - über ein halbes Jahr. Bewegung kam erst in die Sache, als jemand die Wichtigkeit des Bugs am 19.08. von "Undecided" auf "High" geändert hat.

Auszug aus dem Changelog:

shim (15.8-0ubuntu1) mantic; urgency=medium

  * New upstream version 15.8 (LP: #2051151):
    - pe: Align section size up to page size for mem attrs (LP: #2036604)
    - SBAT level: shim,4
    - SBAT policy:
      - Latest: "shim,4\ngrub,3\ngrub.debian,4\n"
      - Automatic: "shim,2\ngrub,3\ngrub.debian,4\n"
      - Note that this does not yet revoke pre NTFS CVE fix GRUB binaries.

Damit sieht die Ausgabe von mokutil --list-sbat-revocations bei mir jetzt so aus:

sbat,1,2023012900
shim,2
grub,3
grub.debian,4

Ubuntu hat also die Versionsnummer für shim von 4 (siehe Beitrag weiter oben) auf 2 heruntergesetzt. Damit klappt's auch wieder mit Secure Boot.

[foobar]

Zur Sicherheit und für die Zukunft nochmal der Hinweis, dass man offenbar auch in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT den Eintrag „OptOut” (Typ DWORD) auf 1 setzen kann (ggf. muss man ihn erst anlegen).

Damit sollte Windows dann auch in Zukunft nicht mehr an der SBAT herum spielen.