Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Navigation
Bezieht sich auf SUSE Linux Enterprise Server 15

11 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 unter 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.

11.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.

11.1.1 Implementierung auf SUSE Linux Enterprise Server

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

Anmerkung
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.

Secure Boot-Unterstützung
Abbildung 11.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.

UEFI: Secure Boot-Vorgang
Abbildung 11.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.

11.1.2 MOK (Machine Owner Key)

Wenn der Benutzer (der Machine Owner, also der Eigentümer des Computers) eine Komponente im Bootvorgang ersetzen möchte, müssen MOKs (Machine Owner Keys) verwendet werden. Das Werkzeug mokutils hilft beim Signieren der Komponenten und beim Verwalten der MOKs.

Der Registrierungsvorgang beginnt mit dem Neubooten des Computers und dem Unterbrechen des Bootvorgangs (z. B. durch Drücken einer Taste), wenn shim geladen wird. shim geht dann in den Registrierungsmodus über, und der Benutzer kann den SUSE-Standardschlüssel durch Schlüssel aus einer Datei auf der Bootpartition ersetzen. Auf Wunsch des Benutzers kann shim dann einen Hash dieser Datei berechnen und das Ergebnis in einer Boot Services Only-Variable ablegen. Damit ist shim in der Lage, Änderungen an der Datei zu erkennen, die außerhalb der Boot-Services vorgenommen wurden; so wird eine Manipulation der Liste der benutzergenehmigten MOKs unterbunden.

Diese Vorgänge laufen zum Zeitpunkt des Bootens ab – nunmehr wird nur überprüfter Code ausgeführt. Daher kann nur ein Benutzer, der direkt an der Konsole sitzt, die Schlüssel des Computereigentümers verwenden. Bei Malware oder bei einem Hacker mit Fernzugriff auf das Betriebssystem ist dies nicht möglich, da Hacker und Malware lediglich die Datei ändern können, nicht jedoch den Hash, der in der Boot Services Only-Variable gespeichert ist.

Nach dem Laden und Überprüfen durch shim ruft der Bootloader wiederum shim auf, um den Kernel zu überprüfen. So wird eine Duplizierung des Prüfcodes vermieden. shim greift hierzu auf dieselbe MOK-Liste zu und teilt dem Bootloader mit, ob der Kernel geladen weden kann.

Auf diese Weise können Sie Ihren eigenen Kernel oder Bootloader installieren. Sie müssen lediglich einen neuen Schlüsselsatz installieren und im Rahmen Ihrer physischen Anwesenheit beim ersten Neubooten bestätigen. Es gibt nicht nur einen MOK, sondern eine ganze MOK-Liste. Aus diesem Grund kann shim die Schlüssel von mehreren Herstellern als verbürgt betrachten, sodass auch Dual- und Multi-Bootfunktionen mit dem Bootloader möglich sind.

11.1.3 Booten eines benutzerdefinierten Kernels

Die folgenden Ausführungen beruhen auf http://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.

  1. 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 http://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificate.

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

    tux > openssl pkcs12 -export -inkey key.asc -in cert.pem \
      -name kernel_cert -out cert.p12
  3. Generieren Sie eine NSS-Datenbank für pesign:

    tux > certutil -d . -N
  4. Importieren Sie den Schlüssel und das Zertifikat aus PKCS#12 in die NSS-Datenbank:

    tux > pk12util -d . -i cert.p12
  5. Authentifizieren Sie den Kernel mit der neuen Signatur mithilfe von pesign:

    tux > pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
      -o vmlinuz.signed -s
  6. Listen Sie die Signaturen im Kernel-Image auf:

    tux > 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.

  7. Konvertieren Sie das Zertifikat zum Importieren in die Firmware oder den MOK in das DER-Format:

    tux > openssl x509 -in cert.pem -outform der -out cert.der
  8. Kopieren Sie das Zertifikat aus Gründen des einfacheren Zugriffs in die ESP:

    tux > sudo cp cert.der /boot/efi/
  9. Mit mokutil wird die MOK-Liste automatisch gestartet.

      1. Importieren Sie das Zertifikat in MOK:

        tux > 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:

        tux > 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:

        tux > 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.

11.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:

  1. Brennen Sie das obige ISO-Image auf eine leere CD/DVD.

  2. 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.

  3. Bei der Installation wird ein initrd mit aktualisierten Treibern herangezogen.

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

11.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.

11.2 Weiterführende Informationen

Diese Seite drucken