it-swarm.com.de

Unterschied zwischen vmlinuz * -generic und * -generic.efi.signed

In /boot gibt es zwei vmlinuz Kerneldateien:

vmlinuz-4.8.0-37-generic
vmlinuz-4.8.0-37-generic.efi.signed

Was ist der Unterschied zwischen diesen beiden Kerneldateien? Wer signiert den zweiten (wenn er tatsächlich signiert ist, wie der Name schon sagt) und wie würde mein UEFI/BIOS wissen, dass es *-generic.efi.signed anstelle von *-generic verwendet?

4
PJ Singh

Der Kernel mit einem Dateinamen, der mit .efi.signed endet, ist von Canonical für die Verwendung mit Secure Boot signiert. Die meisten Computer verfügen jedoch über eine Firmware, die der Canonical-Signatur nicht vertraut. Nur mit Hilfe des Shim-Programms (der shimx64.efi Binärdatei auf dem ESP ) wird dem signierten Kernel vertraut.

Der Ladepfad für signierte Ubuntu-Komponenten mit aktiviertem Secure Boot sieht wie folgt aus:

EFI -> Shim -> GRUB 2 -> Kernel -> Kernel modules
  • Das EFI vertraut Shim, weil es von Microsoft signiert wurde, dessen Schlüssel in die Firmware eingebettet sind.
  • Shim patcht das Secure Boot-Subsystem von EFI und enthält den öffentlichen Schlüssel von Canonical. Shim vertraut GRUB 2, weil es mit dem privaten Schlüssel von Canonical signiert wurde.
  • GRUB 2 ruft das Secure Boot-System von EFI (jetzt von Shim gepatcht) auf, um den Kernel zu überprüfen, der auch mit dem privaten Schlüssel von Canonical signiert ist.
  • Der Kernel überprüft, ob die Kernelmodule mit dem privaten Schlüssel von Canonical oder einem anderen Schlüssel in der Secure Boot-Kette signiert sind.

Vor IIRC, Ubuntu 15.10 erzwang Ubuntus GRUB 2 keine Secure Boot-Richtlinie für den Kernel und der Kernel erzwang keine Secure Boot-Richtlinie für Kernel-Module. Das wurde jedoch kürzlich verschärft. AFAIK, es ist nicht geplant, dass normale System-Binärdateien signiert werden müssen.

Ich weiß nicht ohne weiteres, warum es in Ubuntu eine nicht signierte Kerneldatei gibt. Die signierte Datei funktioniert auch auf Systemen, die Secure Boot nicht unterstützen (einschließlich reiner BIOS-Computer). Daher ist die nicht signierte Datei ziemlich redundant, AFAIK.

Beachten Sie, dass jede der Komponenten ab Shim in vorzeichenloser Form erhältlich ist oder ihre Unterschriften entfernt werden können. Wenn Sie Shim selbst erstellen, können Sie den öffentlichen Schlüssel von Canonical durch Ihren eigenen oder einen beliebigen anderen öffentlichen Schlüssel ersetzen. (Die meisten großen Distributionen haben ihre eigenen Shim-Binärdateien mit ihren eigenen Schlüsseln.) Das Erstellen von Shim aus dem Quellcode wäre sinnlos, es sei denn, Sie veranlassen Microsoft, es zu signieren. Dies würde 100 USD kosten und ein lot der Anstrengung. Wenn Sie selbst signieren müssen, ist das Hinzufügen Ihres Schlüssels als Maschinenbesitzerschlüssel (Machine Owner Key, MOK) einfacher, als Shim neu zu erstellen und von Microsoft signieren zu lassen. Sie können auch die direkt vom EFI unterstützten Schlüsselsätze optimieren, wodurch Shim überflüssig wird. Sie können also viel daran ändern, wie all diese Teile zusammenpassen. Weitere Informationen zum Verwalten von Secure Boot finden Sie unter meine Hauptseite zu Secure Boot und meine Seite zur vollständigen Kontrolle von Secure Boot .

3
Rod Smith

Die signierte Version ist für UEFI Secure Boot. Es wurde mit asymmetrischer Verschlüsselung signiert. Dies bedeutet, dass sich der Schlüssel zum Entschlüsseln von dem zum Verschlüsseln unterscheidet. Das BIOS verfügt nur über einen öffentlichen Schlüssel und kann überprüfen, ob die Signatur korrekt ist (nicht manipuliert wurde). Der private Schlüssel zum Erstellen einer solchen Signatur ist geheim und kann daher nicht selbst erstellt werden. Deshalb vertraut das BIOS ihm und lässt ihn starten.

Für weitere Informationen: https://wiki.ubuntu.com/SecurityTeam/SecureBoot

1
E.F. Nijboer