FOSDEM 25: Booten ohne Bootloader

Grub 2 ist der Bootloader der meisten Linux-Distros, Systemd-boot eine flotte Alternative. Per EFI können bootfähig gemachte Kernel-Images direkt starten.

vorlesen Druckansicht 57 Kommentare lesen
Lesezeit: 5 Min.
Von
  • David Wolski
close notice

This article is also available in English. It was translated with technical assistance and editorially reviewed before publication.

Noch ist der modulare Grand Unified Bootloader in der Version 2.x die Bootmethode, welche die Installer der meisten Linux-Systeme einrichten. Denn die Unterstützung von etlichen Dateisystemen, für EFI, Secure Boot und für Multiboot wappnen Grub 2.x für viele Szenarien. Dabei wächst der Quellcode des in C- und Assembler geschriebenen Grub 2 beständig an und macht eine Pflege aufwändig und die Entwicklung schleppend.

Eine schlanke, moderne Alternative speziell fĂĽr EFI-Systeme ist Systemd-boot, ein minimalistischer Bootloader von Systemd, welcher per EFI-Booteintrag startet und lediglich ein BootmenĂĽ mit verfĂĽgbaren Kernelversionen zeigt.

Dann kann alles weg, meint Marta Lewandowska von Red Hat in ihrem Talk zur FOSDEM 25 – denn startfähige Unified Kernel Images (UKIs) kommen auch ganz ohne Bootloader aus. Bei diesem Konzept, genannt NMBL für „No More Boot Loader“, enthalten die generierten Images alle Zutaten, um ein System bis zum Start des Userspace hochzufahren. Den eigentlichen Boot übernimmt auch hier wie bei Systemd ein EFI-Booteintrag in der Firmware, welcher über eine minimale Grub-2-Emulationsschicht ein Image samt Kernel, vordefinierten Bootparametern und initialer Ramdisk mit allen Treibern für Dateisysteme oder Netzwerkschnittstellen aufruft.

Das Image ist auf Wunsch auch gleich für ein aktiviertes Secure Boot signiert. Der Verzicht auf weitere Helferlein neben EFI zum Systemstart soll laut Lewandowska den Administrationsaufwand hinter der Erstellung von UKIs und deren Booteinträgen reduzieren. Nachdem kein ausgewachsener Bootloader geladen wird, erfolgt der Systemstart mit dieser neuen Methode sehr flott.

Und schließlich ist auch ein Umbooten in ein anderes System in einem Dual-Boot-Szenario per NMBL vorgesehen. Dazu soll ein von NMBL erzeugter EFI-Booteintrag die EFI-Variable „BootNext“ mit einem neuen Pfad zu einer bootfähigen Binary setzen und dann das System neu starten. Dieser Weg hat den Vorteil, dass sich damit auch vordefinierte Systeme starten ließen, die selbst keine gültigen Secure-Boot-Signaturen haben. Denn einen Booteintrag per NMBL kann nur das vertrauenswürdige System anlegen und dann booten – die Vertrauenskette von Secure Boot bliebe also erhalten.

Eine zweite Bootmethode von NMBL bleibt bei einem herkömmlichen Ansatz, wenn Hardware oder Netzwerk-Images mehr Vorbereitung in der Initialisierungsphase benötigen, um das eigentliche Betriebssystem zu starten. Dabei bootet NMBL zunächst die initiale Ramdisk mit minimalem Kernel und einem kleinen Userspace im Stil von Grub 2, kann so auch ein editierbares Menü für die eigentlichen Booteinträge zeigen und lädt dann das ausgewählte System per Kexec. Der Vorteil ist hier immer noch der Verzicht auf einen Bootloader, denn alle diese Schritte inklusive der Menüanzeige erledigt der Linux-Kernel gleich selbst – aus einem einzigen signierten UKI heraus.

Videos by heise

Auf Github liegt NMBL derzeit noch als Vorschauversion ((https://github.com/rhboot/nmbl-poc/)), welche die Plausibilität dieses Ansatzes beweisen will. Das gewählte Linux-System für diese ersten praktischen Demonstrationen von NMBL ist Fedora Linux. Die Scripts von NMBL binden sich als Module in Dracut ein, um eine initiale Ramdisk mit den üblichen Tools aus den Standard-Paketquellen zu erzeugen. Schwierigkeiten bereitet aber noch der so gestartete Linux-Kernel, den Kexec dann starten soll.

Damit dies gelingt, ist auch ein Kernel-Patch nötig. Weitere Experimente mit NMBL werden zunächst im Umfeld Fedoras bleiben, damit die Entwickler dort die passenden Patches für dessen Standard-Kernels pflegen können. In einer ersten Vorstellung des Projekts auf LWN vom Sommer letzten Jahres betonen die Entwickler zudem, dass ihre Tests bisher weitgehend in virtuellen Maschinen mit einer sauberen UEFI-Implementierung erfolgten. Reale Hardware verhält sich erfahrungsgemäß nicht immer brav und berechenbar. Etliche fehlerbehaftete Firmwares zeigen in ihren UEFI-Versionen ein von Standards abweichendes Verhalten beim Boot.

Auf diese Problematik weist auch Lennart Poettering hin, der NMBL bereits voriges Jahr kritisiert hat: Eine Menge der unerwünschten Effekte auf Hardwareebene stellen sich bei der ersten Initialisierung ein. Sein Ansatz per Systemd-boot sei deshalb, möglichst wenig zu laden, nur gerade genug, um ein Menü für die Auswahl von Kernel und initialer Ramdisk zu zeigen. NMBL dagegen muss alles dies mit dem ausgewachsenen, verwendeten Linux-Kernel und einer Ramdisk erledigen, was seiner Ansicht nach sogar mehr Aufwand bedeutete, als einen möglichst simplen Bootloader für EFI-Einträge zu nutzen.

(nen)