Gilt für SUSE Linux Enterprise Server 15 SP4

17 UEFI (Unified Extensible Firmware Interface) #

Die UEFI (Unified Extensible Firmware Interface) bildet die Schnittstelle zwischen der Firmware, die sich auf der Systemhardware befindet, allen Hardware-Komponenten des Systems und dem Betriebssystem.

UEFI wird auf PC-Systemen immer stärker verbreitet und ersetzt allmählich das bisherige PC-BIOS. UEFI bietet beispielsweise echte Unterstützung für 64-Bit-Systeme und ermöglicht das sichere Booten („Secure Boot“, Firmware-Version 2.3.1c oder höher erforderlich), eine der zentralen Funktionen dieser Schnittstelle. Nicht zuletzt stellt UEFI auf allen x86-Plattformen eine Standard-Firmware bereit.

UEFI eröffnet außerdem die folgenden Vorteile:

Booten von großen Festplatten (mehr als 2 TiB) mithilfe einer GUID-Partitionstabelle (GPT).
CPU-unabhängige Architektur und Treiber.
Flexible Vor-OS-Umgebung mit Netzwerkfunktionen.
CSM (Compatibility Support Module) zur Unterstützung des Bootens älterer Betriebssysteme über eine PC-BIOS-ähnliche Emulation.

Weitere Informationen finden Sie im http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface. Die nachfolgenden Abschnitte sollen keinen allgemeinen Überblick über UEFI liefern, sondern sie weisen lediglich darauf hin, wie bestimmte Funktionen in SUSE Linux Enterprise Server implementiert sind.

17.1 Secure Boot #

Bei UEFI bedeutet die Absicherung des Bootstrapping-Prozesses, dass eine Vertrauenskette aufgebaut wird. Die „Plattform“ ist die Grundlage dieser Vertrauenskette; im SUSE Linux Enterprise Server-Kontext bilden die Hauptplatine und die On-Board-Firmware diese „Plattform“. Anders gesagt ist dies der Hardware-Hersteller, und die Vertrauenskette erstreckt sich von diesem Hardware-Hersteller zu den Komponentenherstellern, den Betriebssystemherstellern usw

Das Vertrauen wird durch die Verschlüsselung mit öffentlichen Schlüsseln ausgedrückt. Der Hardware-Hersteller integriert einen sogenannten Plattformschlüssel (Platform Key, PK) in die Firmware, der die Grundlage für das Vertrauen legt. Das Vertrauensverhältnis zu Betriebssystemherstellern und anderen Dritten wird dadurch dokumentiert, dass ihre Schlüssel mit dem PK signiert werden.

Zum Gewährleisten der Sicherheit wird schließlich verlangt, dass die Firmware erst dann einen Code ausführt, wenn dieser Code mit einem dieser „verbürgten“ Schlüssel signiert ist – ein OS-Bootloader, ein Treiber im Flash-Speicher einer PCI-Express-Karte oder auf der Festplatte oder auch eine Aktualisierung der Firmware selbst.

Um Secure Boot nutzen zu können, muss der OS-Loader also mit einem Schlüssel signiert sein, der für die Firmware als verbürgt gilt, und der OS-Loader muss überprüfen, ob der zu ladende Kernel ebenfalls verbürgt ist.

In die UEFI-Schlüsseldatenbank können KEKs (Key Exchange Keys) aufgenommen werden. Auf diese Weise können Sie auch andere Zertifikate nutzen, sofern diese mit dem privaten Teil des PK signiert sind.

17.1.1 Implementierung auf SUSE Linux Enterprise Server #

Standardmäßig wird der KEK (Key Exchange Key) von Microsoft installiert.

Anmerkung: GUID-Partitionstabelle (GPT) erforderlich

Die Secure Boot-Funktion ist in UEFI/x86_64-Installationen standardmäßig aktiviert. Die Option Secure Boot-Unterstützung aktivieren finden Sie auf der Registerkarte Bootcode-Optionen im Dialogfeld Bootloader-Einstellungen. Diese Option unterstützt das Booten, wenn Secure Boot in der Firmware aktiviert ist, wobei Sie auch dann booten können, wenn diese Funktion deaktiviert ist.

Abbildung 17.1: Secure Boot-Unterstützung #

Für die Secure Boot-Funktion ist eine GUID-Partitionstabelle (GPT) erforderlich, die die bisherige Partitionierung per MBR (Master Boot Record) ersetzt. Wenn YaST während der Installation den EFI-Modus feststellt, wird versucht, eine GPT-Partition zu erstellen. UEFI erwartet die EFI-Programme auf einer FAT-formatierten ESP (EFI-Systempartition).

Zur Unterstützung von UEFI Secure Boot ist ein Bootloader mit einer digitalen Signatur erforderlich, den die Firmware als verbürgten Schlüssel erkennt. Die Firmware vertraut diesem Schlüssel a priori und ohne manuelle Intervention.

Hierzu gibt es zwei Möglichkeiten. Die erste Möglichkeit ist die Zusammenarbeit mit Hardware-Herstellern, sodass diese einen SUSE-Schlüssel zulassen, mit dem dann der Bootloader signiert wird. Die zweite Möglichkeit besteht darin, das Windows Logo Certification-Programm von Microsoft zu durchlaufen, damit der Bootloader zertifiziert wird und Microsoft den SUSE-Signierschlüssel anerkennt (also mit dem KEK von Microsoft signiert). Bislang wurde der Loader für SUSE vom UEFI Signing Service (in diesem Fall von Microsoft) signiert.

Abbildung 17.2: UEFI: Secure Boot-Vorgang #

Auf der Implementierungsschicht nutzt SUSE den shim-Loader, der standardmäßig installiert wird. Durch diese elegante Lösung werden rechtliche Probleme vermieden und der Zertifizierungs- und Signierungsschritt wird erheblich vereinfacht. Der shim-Loader lädt einen Bootloader wie GRUB 2 und überprüft diesen Loader; der Bootloader wiederum lädt ausschließlich Kernels, die mit einem SUSE-Schlüssel signiert sind. SUSE bietet diese Funktion ab SLE11 SP3 in Neuinstallationen, in denen UEFI Secure Boot aktiviert ist.

Es gibt zwei Typen von verbürgten Benutzern.

Erstens: Benutzer, die die Schlüssel besitzen. Der PK (Platform Key) ermöglicht nahezu alle Aktionen. Der KEK (Key Exchange Key) ermöglicht dieselben Aktionen wie ein PK, mit der Ausnahme, dass der PK hiermit nicht geändert werden kann.
Zweitens: Benutzer mit physischem Zugang zum Computer. Ein Benutzer mit physischem Zugang kann den Computer neu booten und UEFI konfigurieren.

UEFI bietet zwei Arten von Variablen für die Anforderungen dieser Benutzer:

Der erste Variablentyp sind die sogenannten „authentifizierten Variablen“, die sowohl aus dem Bootprozess (der sogenannten Boot-Dienstumgebung) und dem laufenden Betriebssystem heraus aktualisiert werden können. Dies ist nur dann möglich, wenn der neue Wert der Variable mit demselben Schlüssel signiert ist wie der bisherige Wert der Variable. Zudem können diese Variablen nur an einen Wert mit einer höheren Seriennummer angehängt oder in einen Wert mit einer höheren Seriennummer geändert werden.
Die zweiten Variablen sind die sogenannten „Boot Services Only Variables“ (Variablen für Boot-Services). Diese Variablen stehen jedem Code zur Verfügung, der während des Bootvorgangs ausgeführt wird. Nach Abschluss des Bootvorgangs und vor dem Starten des Betriebssystems muss der Bootloader den Aufruf ExitBootServices auslösen. Anschließend sind diese Variablen nicht mehr zugänglich, und das Betriebssystem kann nicht mehr darauf zugreifen.

Die verschiedenen UEFI-Schlüssellisten sind vom ersten Typ, da es damit möglich ist, die Schlüssel, Treiber und Firmware-Fingerabdrücke online zu aktualisieren, hinzuzufügen und in Schwarze Listen einzutragen. Der zweite Variablentyp, also die „Boot Services Only Variables“, unterstützt die Implementierung von Secure Boot auf sichere, Open Source-freundliche und damit GPLv3-kompatible Weise.

SUSE wird mit shim gestartet, einem kleinen, einfachen EFI-Bootloader, der von SUSE und Microsoft signiert ist.

Damit kann shim geladen und ausgeführt werden.

Anschließend überprüft shim, ob der zu ladende Bootloader verbürgt ist. In der Standardsituation verwendet shim ein unabhängiges SUSE-Zertifikat, das in diesen Loader integriert ist. Darüber hinaus ermöglicht shim das „Registrieren“ weiterer Schlüssel, die Vorrag vor dem SUSE-Standardschlüssel erhalten. Im Folgenden werden diese Schlüssel als MOKs („Machine Owner Keys“) bezeichnet.

Danach überprüft und bootet der Bootloader den Kernel, und der Kernel überprüft und bootet seinerseits die Module.

17.1.2 MOK (Machine Owner Key) #

Wenn bestimmte Kernel, Treiber oder andere Komponenten im Startprozess ersetzt werden sollen, müssen Sie Machine Owner Keys (MOKs) verwenden. Das Werkzeug mokutil unterstützt Sie bei der Verwaltung der MOKs.

Sie können mit mokutil eine MOK-Registrierungsanforderung erstellen. Die Anforderung wird in der UEFI-Laufzeit(RT)-Variablen MokNew gespeichert. Beim nächsten Starten erkennt der shim-Bootloader die Variable MokNew und lädt den MokManager, in dem Sie mehrere Optionen erhalten. Mit den Optionen Schlüssel von Festplatte registrieren und Hash von Festplatte registrieren nehmen Sie den Schlüssel in die MokList auf. Mit der Option MOK registrieren kopieren Sie einen Schlüssel aus der MokNew-Variablen.

Im Normalfall wird ein Schlüssel von der Festplatte registriert, wenn Shim grub2 nicht laden kann und ein Fallback auf das Laden des MokManagers durchführt. Da MokNew noch nicht vorhanden ist, haben Sie die Möglichkeit, den Schlüssel in der UEFI-Partition zu suchen.

17.1.3 Booten eines benutzerdefinierten Kernels #

Die folgenden Ausführungen beruhen auf https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel.

Secure Boot verhindert nicht die Nutzung eines selbst kompilierten Kernels. Sie müssen den Kernel mit Ihrem eigenen Zertifikat signieren und dieses Zertifikat für die Firmware oder den MOK bekanntgeben.

Erstellen Sie einen benutzerdefinierten X.509-Schlüssel und ein entsprechendes Zertifikat für die Signierung:
```
openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
  -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
```
Weitere Informationen zum Erstellen von Zertifikaten finden Sie unter https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificate.

Verpacken Sie den Schlüssel und das Zertifikat als PKCS#12-Struktur:

> openssl pkcs12 -export -inkey key.asc -in cert.pem \
  -name kernel_cert -out cert.p12

Generieren Sie eine NSS-Datenbank für pesign:
```
> certutil -d . -N
```
Importieren Sie den Schlüssel und das Zertifikat aus PKCS#12 in die NSS-Datenbank:
```
> pk12util -d . -i cert.p12
```

„Authentifizieren“ Sie den Kernel mit der neuen Signatur mithilfe von pesign:

> pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
  -o vmlinuz.signed -s

Listen Sie die Signaturen im Kernel-Image auf:
```
> pesign -n . -S -i vmlinuz.signed
```
Zu diesem Zeitpunkt können Sie den Kernel wie gewohnt in /boot installieren. Der Kernel besitzt nun eine benutzerdefinierte Signatur, sodass das Zertifikat zum Signieren in die UEFI-Firmware oder in den MOK importiert werden muss.
Konvertieren Sie das Zertifikat zum Importieren in die Firmware oder den MOK in das DER-Format:
```
> openssl x509 -in cert.pem -outform der -out cert.der
```
Kopieren Sie das Zertifikat aus Gründen des einfacheren Zugriffs in die ESP:
```
> sudo cp cert.der /boot/efi/
```
Mit mokutil wird die MOK-Liste automatisch gestartet.
- 1. Importieren Sie das Zertifikat in MOK:
```
> mokutil --root-pw --import cert.der
```
    Mit der Option --root-pw kann der root-Benutzer direkt verwendet werden.
  2. Prüfen Sie die Liste der Zertifikate, die für die Registrierung vorbereitet werden:
```
> mokutil --list-new
```
  3. Booten Sie das System neu; mit shim sollte MokManager gestartet werden. Um den Import des Zertifikats in die MOK-Liste zu bestätigen, müssen Sie das root-Passwort eingeben.
  4. Prüfen Sie, ob der soeben importierte Schlüssel registriert wurde:
```
> mokutil --list-enrolled
```
- 1. Zum manuellen Starten des MOK gehen Sie alternativ wie folgt vor:
    Booten Sie den Computer neu
  2. Drücken Sie im GRUB 2-Menü die Taste „c“.
  3. Typ:
```
chainloader $efibootdir/MokManager.efi
boot
```
  4. Wählen Sie Enroll key from disk (Schlüssel von Festplatte registrieren).
  5. Navigieren Sie zur Datei cert.der, und drücken Sie Eingabetaste.
  6. Registrieren Sie den Schlüssel gemäß den Anweisungen. In der Regel drücken Sie hierzu „0“ und dann zum Bestätigen „j“.
    Alternativ können Sie einen neuen Schlüssel über das Firmware-Menü in die Signaturdatenbank aufnehmen.

17.1.4 Verwenden von Nicht-Inbox-Treibern #

Das Hinzufügen von Nicht-Inbox-Treibern (also Treibern, die nicht in SUSE Linux Enterprise Server inbegriffen sind) wird bei der Installation mit aktiviertem Secure Boot nicht unterstützt. Der Signierschlüssel für SolidDriver/PLDP gilt standardmäßig nicht als vertrauenswürdig.

Es ist mit zwei Methoden möglich, Treiber von Drittanbietern bei der Installation mit aktiviertem Secure Boot zu nutzen. In beiden Fällen gilt:

Fügen Sie die erforderlichen Schlüssel vor der Installation mithilfe von Firmware-/Systemverwaltungswerkzeugen in die Firmware-Datenbank ein. Diese Option ist von der jeweils verwendeten Hardware abhängig. Weitere Informationen erhalten Sie bei Ihrem Hardware-Händler.
Verwenden Sie ein bootfähiges Treiber-ISO-Image von https://drivers.suse.com/ oder von Ihrem Hardware-Händler, mit dem die erforderlichen Schlüssel beim ersten Starten in die MOK-Liste eingetragen werden.

So tragen Sie die Treiberschlüssel mit dem bootfähigen Treiber-ISO-Image in die MOK-Liste ein:

Brennen Sie das obige ISO-Image auf eine leere CD/DVD.
Starten Sie die Installation von der neuen CD/DVD und halten Sie dabei die standardmäßigen Installationsmedien bzw. die URL zu einem Netzwerkinstallationsserver bereit.
Wenn Sie eine Netzwerkinstallation vornehmen, geben Sie die URL der Netzwerkinstallationsquelle mit der Option install= in die Bootbefehlszeile ein.
Bei einer Installation von optischen Speichermedien bootet das Installationsprogramm zunächst vom Treiber-Kit; anschließend werden Sie aufgefordert, den ersten Installationsdatenträger für das Produkt einzulegen.
Bei der Installation wird ein initrd mit aktualisierten Treibern herangezogen.

Weitere Informationen finden Sie im https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.html.

17.1.5 Funktionen und Einschränkungen #

Beim Booten im Secure Boot-Modus stehen die folgenden Funktionen zur Verfügung:

Installation in den Speicherort des UEFI-Standard-Bootloaders (Mechanismus zum Beibehalten oder Wiederherstellen des EFI-Booteintrags).
Neubooten über UEFI.
Der Xen-Hypervisor wird mit UEFI gebootet, wenn kein Legacy-BIOS für das Fallback vorhanden ist.
Unterstützung für das PXE-Booten mit UEFI IPv6.
Unterstützung für den UEFI-Videomodus; der Kernel kann den Videomodus aus UEFI abrufen und den KMS-Modus mit denselben Parametern konfigurieren.
Unterstützung für das UEFI-Booten von USB-Geräten.

Beim Booten im Secure Boot-Modus gelten die folgenden Einschränkungen:

Um zu gewährleisten, dass Secure Boot nicht einfach umgangen werden kann, sind einige Kernelfunktionen beim Ausführen unter Secure Boot deaktiviert.
Der Bootloader, der Kernel und die Kernelmodule müssen signiert sein.
Kexec und Kdump sind deaktiviert.
Der Ruhezustand (Suspend on Disk) ist deaktiviert.
Der Zugriff auf /dev/kmem und /dev/mem ist nicht möglich, auch nicht als root-Benutzer.
Der Zugriff auf den E/A-Anschluss ist nicht möglich, auch nicht als root-Benutzer. Alle X11-Grafiktreiber müssen einen Kerneltreiber verwenden.
Der PCI-BAR-Zugriff über sysfs ist nicht möglich.
custom_method in ACPI ist nicht verfügbar.
debugfs für das Modul asus-wmi ist nicht verfügbar.
Der Parameter acpi_rsdp hat keine Auswirkungen auf den Kernel.

17.2 Weitere Informationen #

https://www.uefi.org – UEFI-Homepage mit den aktuellen UEFI-Spezifikationen.
Blogeinträge von Olaf Kirch und Vojtěch Pavlík (das obige Kapitel ist stark auf diese Einträge gestützt):
https://en.opensuse.org/openSUSE:UEFI – UEFI mit openSUSE.