Angenommen, ich habe gerade einen signierten EFI-Bootloader (z. B. grub2
von Ubuntu 14.10 amd64 auf einem Lenovo IdeaPad U410, das nur im Secure Boot EFI- oder Legacy-Modus booten kann) auf einem Rechner innerhalb eines Linux- oder (genauer) Debian-basierten Systems installiert. Gibt es eine Möglichkeit, festzustellen, ob der Rechner im laufenden Betrieb booten würde, ohne neu zu starten?
Antwort1
Ja, aber Sie müssen Ihre Secure Boot-Schlüssel zur Hand haben. Beachten Sie zunächst, dass öffentliche Secure Boot-Schlüssel mindestens drei Formen haben können:
.cer
/.der
Dateien – Diese Dateien werden von den meisten UEFI-Implementierungen sowie vom mit Shim gekoppelten Tool MokManager verwendet..crt
– Diese Dateien werden nativ von den meisten Linux-Sicherheitstools wiesbsigntool
und verwendetsbverify
..esl
-- Diese Dateien kombinieren mehrere Schlüssel in einer Datei. (Die anderen Dateien enthalten jeweils einen einzelnen Schlüssel.) Wenn Sie zum Speichern Ihrer Schlüssel eine Firmware-Benutzeroberfläche oder KeyTool verwenden, liegen die resultierenden Dateien in diesem Format vor.
Wenn Sie Ihren eigenen Machine Owner Key (MOK) mit MokManager installiert haben, sollte die Datei im .cer
/ .der
-Format vorliegen. Wenn Sie testen möchten, ob die Binärdatei beim Booten mit einem anderen Schlüssel funktioniert (wie etwa den Schlüsseln, die zum Signieren der GRUB-Version von Ubuntu oder Fedora verwendet werden), müssen Sie diesen besorgen. Der Einfachheit halber habe ich mehrere mit rEFInd gesammelt; Sie können sie stückweise herunterladen.Hier.Wenn Siedie volle Kontrolle über Secure Boot auf Ihrem System übernommen,Sie sollten auch bereits über die von Ihnen erstellten Schlüssel verfügen.
Um eine Binärdatei zu verifizieren, müssen Sie einen Schlüssel im Formular haben . Wenn Sie einen Schlüssel im Formular .crt
haben , können Sie ihn konvertieren:.der
.cer
openssl x509 -in mykey.cer -inform der -out mykey.crt
Anschließend können Sie überprüfen, ob die Binärdatei ordnungsgemäß signiert ist:
sbverify --cert mykey.crt binary.efi
Das Ergebnis sollte eine Nachricht mit dem Inhalt Signature verification OK
oder sein Signature verification failed
.
Beachten Sie, dass einige UEFIs selbst ordnungsgemäß signierte Binärdateien nicht starten. Dies scheint zufällig zu sein; Binärdatei A wird ordnungsgemäß gestartet, während Binärdatei B, die mit demselben Schlüssel signiert ist, fehlschlägt. Ich glaube, dies ist ein Fehler in den betroffenen UEFIs, habe ihn aber nicht im Detail untersucht. Soweit ich weiß, betrifft dies keine über Shim verifizierten Binärdateien, kann aber Shim selbst oder Binärdateien betreffen, die ohne die Hilfe von Shim gestartet werden.