Secure Boot und Setup Mode

mixfreak

New member
Registriert
16 Apr. 2024
Beiträge
1
Hallo,

bei den aktuellen Thinkpads sind ja bekanntlich ab Werk vorinstallierte Keys für die Secure Boot Nutzung installiert, welche man bei Bedarf löschen kann, oder über die "Restore Factory Keys" wiederherstellen kann.

Weiterhin gibt es die Funktion "Reset to Setup Mode", wodurch offensichtlich die Keys gelöscht werden und sich der "Secure Boot Mode" auf "Setup mode" ändert.

Was mich nun irritiert:
Bei aktivieren der "Reset to Setup Mode" und einer anschließenden Windows Installation, bleibt der "Secure Boot Mode" weiterhin auf Setup stehen. Es landen auch keine neuen Keys in den Einträgen unter "Key Mgmt".

Wozu ist diese "Setup Mode" Funktion dann da?

Ein wirklich funktionierenden aktiven Secure Boot kommt hier aktuell nur zustande, wenn ich die "Restore Factory Keys"-Funktion nutze und der "Secure Boot Mode" auf "User Mode" steht.

Wer kennt sich hier genauer aus und kann das Thema "Setup Mode" erklären.

Vielen Dank
Mixfreak
 
Was mich nun irritiert:
Bei aktivieren der "Reset to Setup Mode" und einer anschließenden Windows Installation, bleibt der "Secure Boot Mode" weiterhin auf Setup stehen. Es landen auch keine neuen Keys in den Einträgen unter "Key Mgmt".

"Secure Boot Mode" und "Setup Mode" sind vom Hersteller der Hardware erstellt worden und haben erstmal nichts mit WINDOWS oder Shim zu tun. (Shim macht auf Linux-Systemen Secure Boot nutzbar.)

Ursprünglich war der Flash-Speicher im UEFI, (der hier manchmal fälschlich als NVRAM bezeichnet wird), als Speicher aller Signaturen gedacht, aber dann wurde der Platz zu klein für alle gesperrten Bootloader. Daher hat Microsoft weitere Signaturen gesperrter Bootloader in der komplett verschlüsselten Datei "SkuSiPolicy.p7b" gespeichert. (Diese Datei darf niemals gelöscht werden.)

Der Ablauf beim Start ist nun folgendermaßen: Zuerst prüft das BIOS, ob der Bootloader signiert ist, und dann, ob die Prüfsumme in der DBX steht. Besteht der Bootloader beide Prüfungen, übergibt das BIOS ihm die Kontrolle. Der wiederum startet Windows, (beziehungsweise bei Wechselmediun Windows PE). Das prüft anhand der SkuSiPolicy.p7b, ob der Bootloader überhaupt hätte starten dürfen. Falls nicht, sitzen Sie anschließend vor einem BlueScreen (Fehlercode 0xc0000428, „The digital signature for this file couldn‘t be verified“). Anders als UEFI Secure Boot prüft die Code Integrity Boot Policy den Bootloader also nachträglich. Deshalb erscheint eben ein Bluescreen und keine Secure-Boot-Fehlermeldung des BIOS.

Die neuen Keys sind also aller wahrscheinlich nach in der Datenbank-Datei SkuSiPolicy.p7b gespeichert worden, wenn das installierte WINDOWS noch ohne Bluescreen startet.
Beitrag automatisch zusammengeführt:

Hinweis:
  1. Im Jahr 2024 sollte vor jedem größeren WINDOWS-Update "Secure Boot" temporär abgeschaltet werden, falls die Signaturen durch das WINDOWS-Update und damit die "SkuSiPolicy.p7b" erneuert werden. Für den Fall, dass man einen alten, gesperrten Bootloader benutzt, wird der Rechner trotzdem starten.
  2. Dies ist ein guter Zeitpunkt, alle verwendeten Bitlockerschlüssel auf einem USB-Stick zu sichern (Bitlocker-Laufwerkverschlüsselung -> Wiederherstellungsschlüssel sichern) und eine mit einem Passwort geschützte, gezippte Kopie auf einem One- oder Google-Drive zu halten. Die Bitlocker-Schlüssel sind das Erste, was man nach einem wieder eingeschalteten Secure Boot, anschließenden Crash und dann wieder abgeschaltetem "Secure Boot" braucht...
 
Zuletzt bearbeitet:
Ja Secure Boot, ein toller Spaß! :sick: Wenn ich an den Ärger am T490s unter Debian denke.
 
Der Bootloader liegt auf der EFI System Partition (ESP) im Ordner EFI\Boot.
  • bootia32.efi (x86)
  • bootx64.efi. (x64)
  • bootarm.efi (ARM)
  • bootaa64.efi. (ARM)
Nachdem der Bootloader seine Arbeit erledigt hat (gegebenenfalls BitLocker entsperren, Bootmenü anzeigen und so weiter), übergibt er die Kontrolle üblicherweise an den Windows-Loader C:\Windows\System32\WinLoad.efi, der dann das eigentliche Betriebssystem lädt. Doch zu diesem Zeitpunkt ist alles für Secure Boot relevante längst durch.

Die Secure Boot-Updates liegen auf C:\Windows\System32\SecureBootUpdates
1713300142043.png
Beitrag automatisch zusammengeführt:

Microsoft will demnächst allen vor Mai 2022 erschienenen Bootloadern Startverbot erteilen.
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben