Wenn Secure Boot mehr blockiert als schützt
Sind MBR-Reste und alte Bootloader beseitigt, tauchen Probleme auf: fehlerhafte Einträge im BIOS, unsignierte Treiber oder Linux-Loader, die abgelehnt werden.Artikel teilen
Fall 4: Wenn nur noch der Reset hilft
Nach missglückter Secure-Boot- oder UEFI-Umstellung kann es passieren, dass das BIOS in einer fehlerhaften Konfiguration hängen bleibt. Das äußert sich meist darin, dass Secure Boot zwar aktiviert scheint, aber keine gültigen Schlüssel mehr besitzt oder einfach gar nicht mehr startet. Ursache ist häufig ein Durcheinander in der internen NVRAM-Struktur, etwa wenn zwischenzeitlich von "Custom" auf "Standard Keys" gewechselt oder ein BIOS-Update abgebrochen wurde. In solchen Fällen hilft kein Software-Reset und auch kein "Optimized Defaults". Nur ein kompletter CMOS-Reset - also Strom trennen, Batterie entfernen oder per Jumper zurücksetzen - stellt wieder saubere Startbedingungen her. Erst danach lassen sich die werkseitigen Secure-Boot-Keys (PK, KEK, DB, DBX) neu laden und das System korrekt initialisieren.
Viele Mainboards melden nach so einem Reset, dass Secure Boot "off" sei, obwohl es faktisch nur die Schlüssel verloren hat. Das ist kein Defekt, sondern schlicht ein leerer Sicherheitsrahmen. Wer dann die "Factory Keys" neu einspielt, bringt das System meist ohne weitere Eingriffe wieder in einen gültigen Zustand.
Fall 5: Wenn Treiber plötzlich rausfliegen
Quelle: PCGH
Der unsignierte Treiber einer älteren Auzentech-X-Fi-Karte lässt sich unter Secure Boot nicht mehr laden.
Ein weiteres Phänomen nach der Aktivierung von Secure Boot betrifft alte oder unsignierte Treiber. Während Windows diese jahrelang stillschweigend akzeptiert hat, greift nun eine strengere Validierungskette. Alles, was keinen gültigen Microsoft-Signaturstempel trägt, wird beim Start blockiert, egal, ob das System bislang problemlos lief.
Das trifft vor allem ältere Capture- und Soundkarten, deren Treiber nie für aktuelle Windows-Versionen angepasst wurden. Sie laden Kernelmodule, die nicht mehr den aktuellen Signaturanforderungen entsprechen. Das System startet zwar, verweigert aber den Dienst der betroffenen Hardware oder meldet kryptische Fehler im Geräte-Manager, meist Code 52 ("Windows kann die digitale Signatur für die Treiber nicht überprüfen"). Seltener taucht Code 37 auf, wenn ein Treiber aufgrund fehlerhafter Initialisierung komplett abstürzt. Beide Codes deuten letztlich darauf hin, dass der Kernel den betreffenden Treiber nicht mehr akzeptiert.
Ähnlich sieht es bei Overclocking- und Monitoring-Tools aus, die über eigene Kernel-Treiber arbeiten. Was bislang als "Low-Level-Zugriff" galt, wird jetzt als potenzielle Manipulation gewertet. Gleiches gilt für ältere RGB- oder Lüftersteuerungssoftware, Programme, die tief in den Systemstack greifen, aber nie signiert wurden. Unter Secure Boot ist damit Schluss.
Fall 6: Wenn Linux plötzlich draußen bleibt
Wer sein System im Dual-Boot betreibt, merkt nach der Umstellung auf Secure Boot oft schnell: Linux startet nicht mehr. Ursache ist selten ein beschädigtes System, sondern der Bootloader selbst. Ältere Versionen von GRUB oder Shim wurden in Microsofts DBX-Sperrliste inzwischen als unsicher markiert: ein Schritt, der auf bekannte Schwachstellen wie BootHole zurückgeht. Das Resultat ist eindeutig: "Image failed to verify".
Damit signalisiert das UEFI, dass der verwendete Loader nicht mehr als vertrauenswürdig gilt. Für den Nutzer sieht das zunächst nach einem kaputten Linux aus, tatsächlich greift aber die neue Sicherheitslogik. Wer hier weiterkommen möchte, muss den Bootloader aktualisieren, und zwar idealerweise auf eine Version von Shim ≥ 15.8 oder neuer. Erst diese bringt die aktualisierten Signaturen und den sogenannten SBAT-Support (Secure Boot Advanced Targeting) mit, mit dem sich Bootloader gezielt widerrufen oder wieder freigeben lassen.
Bis dahin gilt: Secure Boot und alte Linux-Installationen vertragen sich nur begrenzt. Wer sein System produktiv nutzt, sollte vor der Umstellung prüfen, ob die verwendete Distribution und der Bootloader noch in der aktuellen DBX-Liste geführt werden. Alles andere endet zuverlässig mit genau dieser Meldung: "Image failed to verify". Das nächste Problem kann schon im TPM lauern. Warum selbst erkannte Module nicht immer als vertrauenswürdig gelten, lesen Sie auf Seite 4.
Kommentare (31)
Zur Diskussion im Forum-
Von XT1024 Volt-Modder(in)Wie ist das, wenn man den halben Tag solch gewollte "Probleme" suchen muss?Zitat von tokenriderEinfach den Schrott nicht kaufen, der so etwas erfordert.
Welche Hardware, auf der man das spielen wollen würde, hat damit ein Problem?
Bla, sülz, TPM ist böse, laber, schwafel.
Ja, das ist bekannt. Gibt es sonst noch irgendwas von Wert?Wegen den 2-3 Foren-Heulsusen, die... was auch immer für obskure Probleme haben?Zitat von tokenriderFirmen leben vom Verkauf. Wenn das Zeug nicht abgenommen wird, ist man gezwungen, etwas besser zu machen.
Sischer dat!
Welche Hardware, auf der man das spielen wollen würde, hat damit ein Problem?
Bla, sülz, TPM ist böse, laber, schwafel.
Ja, das ist bekannt. Gibt es sonst noch irgendwas von Wert?
Sischer dat!
1–2 Jahre abwarten, danach hat sich das Problem von selbst erledigt.
Firmen leben vom Verkauf. Wenn das Zeug nicht abgenommen wird, ist man gezwungen, etwas besser zu machen.
Darum werde ich im Leben nicht einfach leichtfertig Windows 11 und 12 einsetzen.
Denn damit kommt die nächste Welle BS auf uns zu …
habe das aktuellste Bios für das Board drauf, auch wegen der CPU Instabilitäten. Windows 11 meldet auch keine Probleme, alles läuft wie es soll. Hat MSI hier was verbockt?
Anbei Screenshots
Cachy Os schaue ich mir erst noch weiter an.
Bis jezt bin ich aber mit Mint sehr zufrieden, KaOs hatte auch was.....ja ist die Neugier...und Pop!_OS will auch noch getestet werden.
Mir macht da "herumexperimentieren" mir den ganzen Distros im Moment mehr Laune als Bf / CoD zocken.
"Nenne keinen weise, ehe er nicht bewiesen hat, daß er eine Sache von wenigstens acht Seiten her beurteilen kann." -Zitat Konfuzius -