Secure Boot - Buster - vmlinuz invalid signature

Debian auf Notebooks und speziellen Geräten wie eingebetteten Systemen, Routern, Set-Top-Boxen, ...
Antworten
Renatus
Beiträge: 10
Registriert: 30.03.2014 12:34:53

Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Renatus » 12.03.2019 09:00:49

Hallo zusammen,

ich habe auf meinem Dell G3 mit UEFI Secure Boot debian auf Buster testing aktualisiert. Vorher war Stretch im Einsatz.
Um Secure Boot aktiv zu benutzen, musste ich mit KeyTools damals den Dell PK auslesen, um mir daraus ein eigenes Zertifikat zu erstellen und dies Secure Boot hinzufügen. Es ist mir leider nicht möglich andere PKs hinzuzufügen. Dies erlaubt Dell scheinbar nicht.
Jedenfalls habe ich mit meinem eigenen Zertifikat damals bootx64.efi und grubx64.efi signieren können und das booten mit Secure Boot hat funktioniert.
Mit debian Buster kommt wohl nun shim-signed neu dazu. Nach dem Upgrade kamen dann noch die .efi-Dateien fbx64, mmx64 und shimx64 unter \boot\efi\EFI\debian dazu. Und der Bootloader wurde auf shimx64 umgelenkt.
Obwohl ich versucht habe auch die neuen .efi-Dateien zusätzlich mit meinem Zertifikat zu signieren, konnte ich damit nicht im Secure Boot booten.
Ich habe nochmal bootx64 und grubx64 signiert und einen Booteintrag für grubx64.efi hinzugefügt, so dass ich nicht mit shimx64.efi boote. Dies klappt mit Secure Boot, aber sobald ich den Kernel laden will, sagt dieser mir das vmlinuz-4.19.0-2-amd64 eine ungültige Signatur hat. Also habe ich auch diese Datei manuell signiert. Dies hilft aber nicht.
Es bleibt leider bei der Meldung "Invalid signature" sobald ich den Kernel im Secure Boot laden will.

Weiß jemand welche Dateien noch signiert werden müssen, damit der Kernel geladen werden kann? Oder gibt es eine Möglichkeit shimx64.efi selbst zusätzlich mit einem eigenen Zertifikat zu signieren?

Viele Grüße

Renatus
Beiträge: 10
Registriert: 30.03.2014 12:34:53

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Renatus » 12.03.2019 09:20:49

Zusatz: Ich hatte schon damals mit shim experimentiert. Wie auf der SecureBoot/Testing Seite bereits bei einem Dell XPS erwähnt erlaubt die Dell Firmware scheinbar nicht das hinzufügen des Zertifikats, da es mit dem Platform Key nicht passt.
mokutil fails with message Failed to enroll new keys and return code 255

Somit blieb mir nichts anderes übrig als mit dem PK ein eigenes Zertifikat zu erstellen. Dies jetzt shim beizubringen erscheint mir nicht trivial.

Renatus
Beiträge: 10
Registriert: 30.03.2014 12:34:53

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Renatus » 12.03.2019 09:43:11

Ich werde nochmal einige Dokumentationen zu Secure Boot und EFI Boot Loaders durchgehen, und meine .efi Dateien überprüfen ob diese wirklich mit meinem Zertifikat signiert sind.
Vielleicht muss ich das Kernel-Image auch komplett neu erstellen und dies mit einem Signierungsschritt kombinieren. Hab ich so noch nie gemacht.

Nützliche Dokus im Netz:
https://wiki.gentoo.org/wiki/Sakaki%27s ... ecure_Boot
https://www.rodsbooks.com/efi-bootloade ... ng-sb.html
http://www.rodsbooks.com/efi-bootloader ... #preloader
http://blog.cyphermox.net/2017/08/how-t ... -boot.html

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von KP97 » 12.03.2019 15:01:33

Es gibt im Buster Repo auch einen unsignierten Kernel:
https://packages.debian.org/buster/linu ... 4-unsigned

Evtl. hast Du damit mehr Glück.

Renatus
Beiträge: 10
Registriert: 30.03.2014 12:34:53

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Renatus » 12.03.2019 22:20:29

Das hat leider auch nicht geholfen. Hab viel hin und her versucht und zwischendurch sogar die grub.cfg geschrottet.
Alle binaries hatten mein Zertifikat; sbverify gab immer OK zurück.
Das Problem muss irgendwo in grub-efi liegen. Ich kann mich erinnern das ich unter /boot/efi/EFI/debian vor dem Upgrade nur grubx64.efi hatte.
Habe Secure Boot nun im Audit Mode. So wird der Boot wenigstens nicht unterbrochen.

Gibt es Planungen das im UEFI irgendwann kein Secure Boot mehr im Audit Mode eingestellt bzw. abgeschaltet werden kann?

Renatus
Beiträge: 10
Registriert: 30.03.2014 12:34:53

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Renatus » 13.03.2019 08:20:10

Nun habe ich es doch mit shim geschafft.

Ich musste den Custom Mode bei Secure Boot im BIOS deaktivieren und im Audit Mode sein.
Dann konnte ich die Schritte ausführen wie sie unter SecureBoot/Testing beschrieben sind. Natürlich brauchte ich auch wieder den signed-kernel.
Es war natürlich wichtig den Custom Mode zu deaktivieren, damit shim das von debian bereitsgestellte Zertifikat im Keystore ausrollen kann. :facepalm:
Danach aktivierte ich Secure Boot im BIOS wieder im Deploy Mode.

Info von heise:
Microsoft schreibt in den Anforderungen für Komplettsysteme und Notebooks vor, dass das Betriebssystem per UEFI starten und Secure Boot aktiv sein muss; das ist der Grund, warum viele neue PCs die Techniken nutzen. Microsofts schreibt aber auch vor, dass UEFI Secure Boot über das Setup der UEFI-Firmware ausschaltbar sein muss – bei manchen Systemen ist es allerdings alles andere als offensichtlich, wie man das macht.
Immerhin und hoffentlich bleibt es dabei für die Zukunft.

Benutzeravatar
rockyracoon
Beiträge: 1452
Registriert: 13.05.2016 12:42:18
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von rockyracoon » 13.03.2019 10:46:57

Ich habe Secure-Boot und Fast-Boot deaktiviert.
Secure-Boot erscheint mir nicht sonderlich "secure" zu sein und Fast-Boot bringt meiner Meinung nach kaum Vorteile, sondern stresst eine SSD unnötig.
Überhaupt erscheint mir bei diesen durch Microsoft angestoßenen "UEFI-Neuerungen" nur die GPT-Partitionierung Sinn zu machen.

Monroe
Beiträge: 67
Registriert: 26.10.2015 21:00:04

Re: Secure Boot - Buster - vmlinuz invalid signature

Beitrag von Monroe » 25.08.2019 13:36:54

Buster gefällt mir auf meinem Dualboot ( Win/Debian) Notebook mit mehreren *.iso Live images ganz und gar nicht, wenn man secure boot im BIOS aktiviert und mit shim bootet. Ich gebe zu, dass ich anspruchsvoller User bin, der mit Debian Jessie und Stretch bisher immer gut gefahren ist, doch auf virtualbox kann und will ich nicht verzichten und kann da auch nicht viel Zeit investieren. Ok, secureboot Implementierung beinhaltet zusätzliche Security, die ich auch wichtig finde, doch braucht es dazu viel Zeit, die ich – wie gesagt – nicht habe.
Ich habe das versucht mit der Anleitung von 2016, doch wer kommt auf solch eine Idee? :facepalm:

Antworten