Linux unterliegt einem ständigen Wandel. Das betrifft auch den Bootvorgang, denn Bootloader wie Grub kommen langsam aus der Mode.

Linux-Nutzer der ersten Stunde starteten ihre Systeme vor 20 oder mehr Jahren in aller Regel mit dem Bootmanager Lilo (Linux Loader). Dessen Entwicklung begann 1992, die letzte Version wurde 2015 veröffentlicht. Lilo hatte jedoch einen entscheidenden Nachteil: Es konnte keine Dateisysteme lesen und musste daher die genauen Speicheradressen des Kernels kennen. Jede Kernel-Aktualisierung erforderte ein erneutes Einlesen der belegten Blöcke, bevor das System booten konnte. Trotz dieser Einschränkung war Lilo einfach zu konfigurieren und kam während des Bootvorgangs ohne Dateisystemunterstützung aus, da es den Kernel direkt vom zuvor ermittelten Speicherort auf der Festplatte las (Abbildung 1).

Abbildung 1: Lilo, das ohne Dateisystemunterstützung auskam, war um die Jahrtausendwende ein viel benutzter und einfach zu bedienender Bootloader.

Das war neben der größeren Flexibilität bei Dateisystemen und Installationszielen dann auch der Hauptgrund dafür, dass um die Jahrtausendwende der Grand Unified Bootloader (Grub) Lilo allmählich den Rang ablief. Heutige Systeme booten in der Mehrheit mit dem 2012 erstmals veröffentlichten Grub 2. Der neue Bootloader kann nicht nur mit verschiedensten Dateisystemen umgehen, sondern auch mit Verschlüsselung, Kompression und RAID. Systeme, die Systemd zur Initialisierung verwenden, können seit einiger Zeit alternativ das aus dem Bootloader Gummiboot hervorgegangene Systemd-Boot [1] einsetzen.

Grub lässt sich auf verschiedenen Architekturen einsetzen, kann auf Netzwerke zugreifen und unterstützt eine Vielzahl von Dateisystemen sowie Datenträgertypen (Abbildung 2). Damit bietet er deutlich mehr Funktionalität, als die meisten Anwender tatsächlich benötigen. In den letzten Jahren traten bei Grub allerdings zahlreiche mittel bis hoch eingestufte Sicherheitslücken auf. Der Bootloader steht daher zunehmend in der Kritik. Seine umfangreiche Codebasis mit über einer halben Million Zeilen gilt als überladen und anfällig für Fehler sowie Angriffe. Außerdem erschwert die verteilte Konfiguration über mehrere Dateien an unterschiedlichen Orten Einsteigern den Überblick. All das deutet darauf hin, dass das Bootloader-Urgestein seine Blütezeit möglicherweise hinter sich hat.

Abbildung 2: Auch wenn man es ihm nicht ansieht: Grub ist wesentlich leistungsfähiger als Lilo. Seine großer Funktionsumfang macht ihn aber auch fehleranfällig. (C) Huihermit, GPL, https://commons.wikimedia.org/w/index.php?curid=44678809

Setzt sich der Systemd-Entwickler Lennart Poettering mit seinen Visionen zur Zukunft von Linux-Distributionen durch, könnte der klassische Bootloader bald obsolet werden. In Poetterings Konzept übernimmt der Linux-Kernel selbst die Bootaufgaben. Das realisiert er mithilfe sogenannter Unified Kernel Images, deren Entwicklung Fedora aktuell vorantreibt. Um die Vorteile dieses Ansatzes zu verstehen, lohnt sich ein Blick auf den traditionellen Linux-Bootvorgang.

Normalbetrieb

Das Einschalten des PCs aktiviert zunächst das BIOS oder UEFI. Beide starten Initialisierungsroutinen inklusive eines Power-on Self-Tests (POST) und überprüfen die grundlegende Hardware. Erst dann startet der eigentliche Bootvorgang: Der Bootloader (in der Regel Grub 2) wird entweder vom Master Boot Record (MBR) oder der EFI-Partition in den Arbeitsspeicher geladen. Anschließend lädt er den Linux-Kernel sowie das initiale RAM-Dateisystem Initramfs in den Arbeitsspeicher (Abbildung 3).

Abbildung 3: Bootloader wie Grub 2 sorgen für einen geordneten Systemstart mit allen nur denkbaren Hardware-Konstellationen.

Im Arbeitsspeicher dekomprimiert sich der Kernel selbst und übernimmt die Kontrolle vom Bootloader. Er initialisiert die Speicherverwaltung, erkennt zusätzliche Hardware und richtet eine minimale Umgebung ein. Darin werden Hardwarekomponenten initialisiert, benötigte Gerätetreiber geladen und anschließend das temporäre Root-Dateisystem Initramfs eingehängt. Dessen Hauptaufgabe besteht darin, essenzielle Treiber und Programme wie Udev bereitzustellen, die das Mounten des eigentlichen Root-Dateisystems ermöglichen. Hier beginnt die Init-Phase mit dem ersten Prozess /sbin/init (PID 1), der den weiteren Systemstart koordiniert. Nach dem Überprüfen und Einhängen aller Dateisysteme sowie dem Wechsel in den Single- oder Multi-User-Modus ist das System vollständig betriebsbereit.

Wie dieser Ablauf zeigt, handelt es sich um einen komplexen Prozess mit vielen ineinandergreifenden Komponenten. Das Gesamtkonstrukt ist fehleranfällig und nur schwer vollständig abzusichern. Angreifer könnten das BIOS oder die Firmware manipulieren, um Malware zu installieren oder die Kontrolle über das System zu erlangen. Solche Attacken sind besonders tückisch, da sie mit Standardmethoden oft lange Zeit unentdeckt bleiben. Ebenso besteht die Gefahr von Bootloader-Manipulationen, die Rootkits oder Backdoors platzieren, das Laden kompromittierter Betriebssysteme ermöglichen oder schädlichen Code bereits im frühen Bootprozess ausführen.

Booten ohne Bootloader

Lennart Poettering leistete wie so oft die Vorarbeit [2] für die bei Fedora und Red Hat umgesetzten Sicherheitskonzepte des Bootvorgangs. Eine Schlüsselrolle übernimmt hier der Sicherheitschip TPM 2.0, über den LinuxUser bereits im Kontext der Vollverschlüsselung berichtete [3].

TPM (Trusted Platform Module) bezeichnet einen Mikrocontroller, der PCs und Notebooks mit grundlegenden Sicherheitsfunktionen ausstattet. Er ermöglicht eine Trusted-Computing-Plattform, die Manipulationen während des Bootvorgangs erkennt. In der Praxis erzeugt die CPU für jede Bootkomponente kryptografische Hashes, die sie an das TPM übermittelt. Das Trusted Platform Module speichert die Werte und gibt den Entschlüsselungs-Key nur bei Übereinstimmung mit den Referenzwerten frei (Measured Boot). Bei jedem Systemstart erzeugt das TPM neue Prüfsummen und vergleicht sie mit den gespeicherten – ein wirksamer Schutz gegen softwarebasierte Angriffe auf den Bootvorgang und insbesondere auf die Initrd.

Die distributionsübergreifende Arbeitsgruppe UAPI [4] koordiniert seit 2022 die Community-Entwicklung moderner Linux-Derivate. Sie sammelt Spezifikationen, Dokumentation und Ideen, darunter Konzepte für einen neuen Bootprozess. Poetterings Vorschlag von 2022 sieht einen vollständig signierten und verifizierten Ausführungspfad von der Firmware bis zum Userspace vor, gesichert durch TPM 2 und optional Secure Boot. Den Kern des Konzepts bildet das Unified Kernel Image (UKI [5]), das seit Jahren existiert. Es kombiniert das Linux-Kernel-Image, Initrd, die Kernel-Kommandozeile und einen UEFI-Boot-Stub wie Systemd-stub [6].

All diese Komponenten packt das System in eine ausführbare UEFI-Datei, die entweder direkt von der UEFI-Firmware oder über einen Bootloader startet. Beim Ausführen lädt es den Linux-Kernel mit den vorgegebenen Befehlszeilenoptionen. Er bindet dann die Initrd ein und startet das restliche System. Das Tool Ukify [7] erstellt solche UKIs als EFI-PE-Paket (Portable Executable) für die UEFI-Firmware.

UKIs bieten mehrere Vorteile: Atomare Updates aller Komponenten in einem Schritt erhöhen die Sicherheit, besonders angesichts der Tatsache, dass die UEFI-Systempartition (ESP) auf einem FAT-Dateisystem mit begrenzter Datensicherheit liegt. Als reguläre UEFI-Dateien lassen sich UKIs zudem komplett für Secure Boot signieren. Standardwerkzeuge wie Sbsigntool, Systemd-sbsign und Pesign eignen sich dafür.

No more Bootloader

Die Theorie fand praktische Anwendung, als Fedora-Entwickler das Konzept No more Bootloader (Nmbl) umsetzten (Abbildung 4). Statt auf separate Bootloader zu setzen, nutzt dieser Ansatz über UEFIs EFI-Stub-Funktionalität und Unified Kernel Images den Linux-Kernel selbst.

Abbildung 4: Nmbl wird zunächst auf der Basis des aktuell gestarteten Kernels gebaut. Am einfachsten gelingt das mit Fedora 39, worauf das Make-Skript zugeschnitten ist.

Der entscheidende Vorteil liegt in der Codebasis: Während Grub mit über 500 000 Codezeilen als komplex und wartungsintensiv gilt, benötigt der Kernel nur wenige Hundert zusätzliche Codezeilen für den Bootvorgang. Die schlankere Architektur reduziert nicht nur Fehlerquellen, sondern profitiert auch von der deutlich größeren Kernel-Entwicklergemeinde: Probleme lassen sich so schneller identifizieren und beheben als bei herkömmlichen Bootloadern. Der Ansatz zeigt, wie sich durch Vereinfachen des Bootprozesses gleichzeitig Sicherheit und Wartbarkeit verbessern lassen – ein Paradigmenwechsel weg von monolithischen Bootloadern hin zu integrierten Lösungen.

Im Sommer 2023 dokumentierten die Entwickler in einem Blog-Beitrag [8] ihre Motivation und die Fortschritte bei Nmbl. Der Konzeptnachweis präsentierte zwei Implementierungswege. Der erste Ansatz nutzt Kexec [9], einen Systemaufruf zum Laden eines neuen Kernels aus dem laufenden System heraus. Der zweite setzt auf Switch-Root, das mit demselben Kernel arbeitet und nur vom frühen Userspace zum finalen Root-Dateisystem wechselt. Die Entwickler erwarten einen häufigeren Einsatz von Switch-Root, behalten aber mit Kexec die Option, per Menüauswahl alternative Kernel zu starten. Diese Flexibilität zeigt, wie Nmbl traditionelle Bootloader-Funktionalität schlank und sicher integriert.

Nmbl befindet sich noch in der Proof-of-Concept-Phase, funktioniert aber bereits auf UEFI-Systemen. Fedora-Benutzer testen es, indem sie zunächst Nmbl bauen, dann UKIs mit Tools wie Dracut erstellen und EFI-Einträge manuell konfigurieren. Ein Blogpost [10] erklärt, wie man Nmbl mit Fedora 39 baut. Neben der Möglichkeit, Secure Boot außen vor zu lassen, beschreibt der Eintrag auch, wie man für Secure Boot seinen eigenen Schlüssel erstellt, das UKI damit signiert (Abbildung 5) und somit einen Measured Boot umsetzt [11]. Wie daraus ein bootfähiges Paket wird, beschreibt ein Eintrag auf Github [12].

Abbildung 5: Ein Blick in das Bootverzeichnis nach dem Erstellen eines Nmbl zeigt die verschiedenen Vorlagen für die Erstellung und Signierung von UKIs.

Fazit und Ausblick

Fedora und Red Hat arbeiten an einem System ohne externen Bootloader. Das Projekt Nmbl, aktuell noch in der Konzeptphase, integriert den Bootvorgang in ein einziges Paket und startet den Kernel direkt über einen EFI-Stub. TPM 2.0 und optional Secure Boot sorgen für den nötigen Schutz.

Zwar gibt es den EFI-Stub-Ansatz bereits seit Jahren, für die Mehrheit der Nutzer blieb er aber unpraktikabel. Führt Fedora Nmbl als Standardmethode für den Systemstart ein, profitieren Benutzer nicht nur von erhöhter Sicherheit, sondern auch von kürzeren Startzeiten. Kernel-Updates reduzieren sich auf das Anpassen eines UKI, ohne umständliche Bootloader-Konfiguration. (tle)