UEFI: So funktioniert der Bios-Nachfolger

Hard- und Software-Hersteller sind sich einig, dass es höchste Zeit war, das vom IBM-PC geerbte Bios gegen eine richtige Firmware zu ersetzen. Seit 2010 sind Mainboards und Notebooks mit Uefi ausgestattet. Uefi (Unified Extensible Firmware Interface) ist keine Weiterentwicklung des Bios, sondern basiert auf EFI, das Intel zunächst Ende der 90er-Jahre für die eigenen 64-Bit- Server der Itanium-Plattform einführte. Die Spezifikation von Uefi untersteht hingegen dem Unified EFI Forum, in dem Entwickler verschiedener Hersteller an verbindlichen Standards und optionalen Erweiterungen wie Secure Boot arbeiten. Dabei handelt es sich um keine Geheimwissenschaft. Intels Referenz- Version von Uefi mit dem Namen „Tianocore“ ist Open Source, steht unter der BSD-Lizenz und ist im Quelltext unter https://tianocore.sourceforge.net freigegeben. Darauf basieren auch alle anderen herstellerspezifischen Uefi-Varianten. Ausgenommen sind Firmware-Treiber zur Initialisierung der speziellen Hardware, wie CPU und Speicher-Controller, die von Herstellern selbst entwickelt werden. Auch damit ist Uefi schon deutlich umfangreicher als das in x86-Assembler geschriebene Bios: Ohne Hardware-Treiber umfasst der Quellcode von Uefi rund 100 MB.

Übersicht: Der Uefi-Bootprozess

Aufgabe von Uefi ist es, eine Schnittstelle zwischen Hardware und Betriebssystem zu stellen und das System nach dem Start dem Betriebssystem zu übergeben. Zusätzlich umfasst die Uefi-Spezifikation eine API-Schnittstelle, um den Bootprozess und die Booteinträge von einem laufenden Betriebssystem aus konfigurieren zu können. 1. Nach dem Einschalten eines Uefi- Systems erwacht die Hardware zunächst wie bei einem herkömmlichen Bios mit einem internen Selbsttest (Power- on Self-Test, kurz POST). 2. Ist alles in Ordnung, wird Uefi als Firmware geladen. Sie übernimmt die Initialisierung aller für den Start nötigen Geräte und lädt optionale Erweiterungen wie Secure Boot. 3. Anders als Bios kann Uefi kann mit GPT- sowie MBR-Partitionen und dem FAT-Dateisystem umgehen. Es sucht alle Datenträger nach einer per GUID (Globally Unique Identifier) markierten EFI System Partition (ESP) ab. Auf dieser Partition sind die EFI-Programme hinterlegt, die Bootloader für Uefi-Werkzeuge und für installierte Betriebssysteme enthalten.

4. Der Uefi-Bootmanager führt den im NVRAM des Firmware-Chips als Standard festgelegten Bootloader für ein Betriebssystem aus oder präsentiert ein vom Hardware-Hersteller gestaltetes Menü zur manuellen Auswahl von EFI-Bootloadern oder Partitionen. Natürlich können nicht alle Betriebssysteme mit Uefi umgehen und entsprechende Bootloader auf der ESP hinterlegen. Deshalb hat Uefi laut Spezifikation einen im Firmware-Menü aktivierbaren Kompatibilitätsmodus (CSM – Compatibility Support Module), der das System wie altes Bios per MBR starten kann. 5. Wenn es das Betriebssystem zulässt, kann es der EFI-Bootloader direkt starten. Im Fall von Linux-Systemen lädt der EFI-Bootloader aber erst einen vorgeschalteten Bootloader wie Grub 2, der schließlich den Linux-Kernel und das Initramfs startet.

Windows & Ubuntu auf UEFI-Systemen installieren

Der Bootmanager von Uefi

Nach dem Start ist das Betriebssystem für den Rechner zuständig und kann mit eigenen Tools Uefi-Bootloader im Bootmanager der Firmware einrichten und ändern. Unter Uefi-fähigen Linux-Distributionen wie Ubuntu, Debian, Fedora und Open Suse dient das Kommandozeilen-Tool efibootmgr zur Abfrage und Konfiguration des Uefi-Bootmanagers. Das Tool steht nur für 64-Bit-Versionen bereit, da momentan noch kein 32-Bit-Linux Uefi unterstützt. Die Eingabe

gibt aus, welcher Bootloader gestartet wurde („BootCurrent“), den Timeout zum Start des Standard-Bootloaders („Timeout), die eingestellte Bootreihenfolge („BootOrder“) sowie die Liste der hinterlegten Bootloader („Boot0000, Boot0001, Boot0002“…). Jeder dieser Bootloader-Einträge enthält den Namen des Systems, in der Klammer hinter „HD“ die GUID der Festplatte, die den Bootloader enthält, und hinter „File“ den Dateinamen des EFI-Bootloaders. Falls CSM aktiviert ist, zeigt die Liste außerdem Einträge für einen Bios-kompatiblen Start über einen MBR. Diese Einträge beginnen die Laufwerks-Definition mit „Bios“, gefolgt von der Bus-ID des Datenträgers. Tipp: Die verschiedenen Installer von Linux-Distributionen greifen alle auf efibootmgr für eine Installation im Uefi-Modus zurück, und das Tool unterstützt eine Reihe von Parametern, um Einträge anzulegen und zu löschen. Bei manuellen Änderungen der Einträge ist große Vorsicht geboten, um nicht versehentlich einen Bootloader zu löschen. Ein gefahrloses Anwendungsbeispiel für efibootmgr ist hingegen die Änderung der Bootreihenfolge. So legt das Kommando

den Eintrag „Boot0000“ als ersten zu startenden Eintrag und „Boot0001“ als den zweiten Eintrag fest.

Linux im Uefi-Modus installieren

Die aktuellen Linux-Distributionen unterstützen in ihrer 64-Bit-Version den Start im Uefi-Modus. Nur wenn ein System in diesem Modus gestartet ist, klappt auch die Uefi-Installation, andernfalls richten die Installer das System im Bios-Modus ein. Die Vorzüge des Uefi-Bootmanagers, der die Einrichtung von Multiboot-Systemen erleichtert, stehen dann nicht zur Verfügung. Ist CSM aktiviert, ist nicht immer gleich ersichtlich, in welchem Modus das Installationsmedium für ein Linux-System nun läuft. Ein verlässlicher Indikator ist dieses Kommando:

Bleibt die Ausgabe leer, dann läuft das System im Bios-Modus und wird sich mit dem Installer auch nur in diesem Modus installieren lassen. Im Uefi-Modus zeigt der Befehl hingegen den Pfad zur Firmware an. Die diversen Installer werden dann bei einer geführten Installation das resultierende System im Uefi-Modus installieren und dabei die Bootloader-Einträge automatisch installieren.

Sonderfall Secure Boot

Ein Merkmal von Uefi ist der modulare Aufbau. So wie mit CSM ein Modul zur Bios-Kompatibilität geladen werden kann, kann Uefi auch Secure Boot laden. Secure Boot legt fest, dass die Firmware einen Satz asymmetrischer kryptographischer Schlüssel enthalten kann: Der Plattform Key (PK) des Hardware-Herstellers, dessen öffentlicher Teil im NVRAM gespeichert ist, sorgt dafür, dass nur vertrauenswürdige Firmware und signierte Bootloader zugelassen sind. Zusätzliche Key Exchange Keys (KEK), die wiederum mit dem privaten Teil des PK signiert sind, sorgen dafür, dass Betriebssystem- Hersteller eigene Schlüssel zum Start von Systemen speichern können. Bei aktiviertem Secure Boot muss der Bootloader also mit einem Schlüssel signiert sein, der auf den privaten PK zurückgeht. Zudem gibt es eine „schwarze Liste“ an gesperrten Schlüsseln für Malware, deren Bootloader nicht gestartet wird. Das alles liest sich in den Spezifikationen ganz nützlich – aber dann kommt Microsoft ins Spiel: Microsoft verlangt von Herstellern und OEMs, alle PCs mit Windows 8, die sich mit dem Windows- Logo schmücken möchten, mit aktiviertem Secure Boot auszuliefern. Hier ist der KEK von Microsoft in der Firmware vorinstalliert. Natürlich könnten Hersteller Secure Boot auch einfach abgeschaltet lassen, aber dann entgehen ihnen die vergünstigten OEM-Versionen von Windows 8, und das Gerät wäre teurer. Damit auch Linux-Systeme mit Secure Boot unabhängig vom Hersteller starten, haben die größeren Distributionen ihren Bootloader von Microsoft für die nominale Gebühr von 99 US-Dollar zertifizieren lassen, damit diese mit dem vorinstallierten KEK von Microsoft funktionieren. Generell aber sollten Linux-Nutzer, die nicht auf die Sicherheit von Secure Boot angewiesen sind, den ganzen Spuk einfach im Uefi-Setup deaktivieren. Laut Spezifikation muss sich Secure Boot in jeder Uefi-Version abschalten lassen.

Alle Details zu UEFI-Firmware

Praktische Probleme des Uefi-Standards

Auch wenn Linux-Distributionen Uefi nach den Spezifikationen voll unterstützen, gibt es mit verschiedenen Herstellern Inkompatibilitäten. Denn ein Problem des Uefi-Standards ist die laxe Umsetzung von verbindlichen Standards. Uefi gibt lediglich vor, was eine Firmware mindestens können muss, um als Uefi-konform zu gelten. Hersteller können darüber hinaus aber neben Hardware-Treibern noch viele Ausnahmen hinzufügen. So fand es Apple nötig, bei einigen Macs die vorinstallierten Bootloader nicht auf einer ESP mit FAT unterzubringen, sondern mit dem Dateisystem HFS+. Keine Vorschriften gibt es außerdem bei der Gestaltung der Menüoberfläche für die Firmware-Einstellungen. Wichtige Funktionen, wie etwa jene zum Deaktivieren von Secure Boot und zum Einschalten von CSM können von Herstellern andere Namen bekommen und an verschiedenen Stellen in den Menüs untergebracht sein. Gerade beim Einsatz von Linux ist das ein Problem: Anwender mit Einsteiger-Wissen und einem neuem Windows-8-Notebook tun sich schwer, Secure Boot zum Start eines Live-Systems in den Firmware-Menüs zu finden und abzuschalten. Auch die BSD-Lizenz von Uefi hat ihre Schattenseiten: Offenbar übernehmen Hersteller bisweilen den Code. Das ist zwar deren gutes Recht, jedoch geschieht es oft, ohne die fertige Firmware auf realer Hardware zu testen. So gibt es Uefi-Notebooks, auf welchen sich weder Linux noch Windows 8 im Uefi-Modus installieren lassen. 2013 lieferte Samsung Notebooks (Modell 300E5C S04) aus, bei welchem der reservierte Speicherbereich für Crash-Dumps Teile der Firmware überschreibt, falls dort wirklich Daten abgelegt werden. Auf einigen Lenovo-Modellen der 4000-Serie von 2014 kann die Installation von Linux im Uefi-Modus oder der Austausch der Festplatte die Firmware wegen eines Bugs in Lenovos Uefi-Version irreparabel beschädigen. Uefi stellt also offensichtlich nicht nur Endbenutzer vor neue Herausforderungen.