FOSDEM: Ausblick auf den Bootloader Grub 2.12

Einer der maßgeblichen Köpfe hinter Grub, Daniel Kiper von Oracle, hat auf der diesjährigen FOSDEM (die als Online-Veranstaltung stattfindet) den Zustand und die weiteren Pläne für den verbreiteten Bootloader in einem aufgezeichneten Talk skizziert. Die Pflege des Quellcodes in C und Assembler ist eine Herausforderung geblieben, was sich in der eher schleppenden Entwicklung zeigt und auch eines der Themen des Talks war.

Auch wenn es viele Möglichkeiten gibt, ein Linux-System auf x86-Hardware zu booten, so ist der Bootloader Grub doch die verbreitete Methode. Der Grund, weshalb die meisten Linux-Distributionen Grub in Version 2.04 oder auch schon in der aktuellen Ausgabe 2.06 nutzen, liegt in der Verfügbarkeit etlicher Module für Multiboot-Konstellationen, für etliche Dateisysteme, für EFI und Secure Boot. Grub – kurz für GNU Grand Unified Bootloader – war in Version 2 vor zehn Jahren komplett neu geschrieben worden, um etliche Probleme mit Grub Legacy auf moderner Hardware zu lösen und dazu auch Code von anderen Open-Source-Projekten wie dem Vorläuferprojekt PUPA zu übernehmen.

Grub 2.06: Boothole und andere Lücken

Der lange Weg zu Grub 2.06, erschienen im Juni 2021 mit fast einem Jahr Verspätung, war laut Kiper vor allem von Fixes für Sicherheitslücken geprägt. Nach Boothole, das Secure Boot unter bestimmten Umständen aushebelte, folgten Boothole 2 und dann acht weitere Lücken, die vor allem auf Probleme im Speichermanagement der C-Programmteile hinweisen. Das Management der Speicherbereiche bezeichnet Kiper auch als jene Hürde, welche den Entwicklungsprozess weiterhin zäh gestaltet, ebenso die Aufräumarbeiten und länger diskutierte Entscheidungen über die Entfernung von Features zur Abwärtskompatibilität.

Dazu gehört die Größe des traditionellen Master Boot Record (MBR), die bis Grub 2.06 mit 31 Kilobyte festgelegt war. Auf modernen Datenträgern wie SSDs und NVMEs führt dies zu einer ungünstigen Ausrichtung von Dateisystemblöcken und Speicherseiten. Es ist deshalb üblich, 1 Megabyte am Anfang eines Datenträgers für den MBR zu reservieren. Grub 2.06 verarbeitet deshalb ebenfalls keine kleineren MBR-Größen mehr oder nur noch über manuelle Workarounds. Zudem beherrscht der Bootloader im Zuge dieser Aufräumarbeiten LUKS2 sowie den Start von BTRFS-Partitionen, deren reservierte Bereiche Grub jetzt nutzen kann.

Ausblick auf Grub 2.12: Rust statt Frust

Für 2022 haben sich die Grub-Entwickler eine Beschleunigung des Review- und Test-Prozesses vorgenommen. Ziel ist eine jährliche, zügige Veröffentlichungsweise des Bootloaders, den es bisher in der aktuellen Version bei Fedora 35 und Arch Linux in deren Paketquellen geschafft hat, während Ubuntu und Debian noch bei Version 2.04 verharren. Aktuell verzögern einige Blocker-Bugs im Speichermanagement die Aufnahme weiterer Patches, die dann Mitte dieses Jahres in das angekündigte Grub 2.12 eingehen sollen. Damit dies gelingen kann, kümmert sich das Entwicklerteam gerade um den Aufbau systematischer Testmethoden, in der Hoffnung, einige davon automatisieren zu können. Außerdem sollen an Prozessorarchitekturen RISC-V und Loongson Architecture, kurz LoongArch, hinzukommen.

Wegen vergangener Bugs und Sicherheitslücken schlägt IBM-Entwickler Daniel Axtens vor, Teile von Grub in Rust neu zu schreiben. Dies hätte den Vorteil, dass ein sicheres Speichermanagement schon während des Kompilierens des Rust-Programmcodes sichergestellt wäre. Denn Rust erlaubt durch seine stringenten Zugriffsmodelle die typischen Pointer-Fehler von C nicht, welche den Grub-Programmierern offensichtlich so viel Kopfzerbrechen bereiten. Der Aufwand dahinter ist allerdings nicht gering, denn ohne Neustrukturierung von mehrfach genutzten Speicherbereichen tut auch Rust nicht, was es soll. Es sollen für Grub 2.12 also erst mal nur einzelne Module auf Rust portiert werden.

Im Zug eines längeren Ausblicks ging Kiper in seinem Talk (der gegen Ende der FOSDEM 22 als Aufzeichnung bereitgestellt wird) noch auf die unterschiedlichen Grub-Versionen ein, welche von tonangebenden Linux-Distributionen derzeit in Gebrauch sind. Aufgrund der langen Wartezeiten zwischen Grub-Versionen halten Maintainer den Bootloader mit eigenen Patches und Modulen fit für moderne Hardware, so gut dies eben geht. Diese Sonderwege sorgen auf älteren Systemen wie Ubuntu 18.04 immer wieder für Probleme nach Updates. Erklärtes Ziel des Grub-Teama ist es deshalb, die Veröffentlichungsgeschwindigkeit so weit anzuziehen, dass Distributionen in drei bis vier Jahren keine eigenen Patches auf ihren Grub-Paketen anwenden müssen. Als Beispiel dafür, dass dieses Vorhaben schon auf einem guten Weg ist, führte der Talk Fedora 35 an, das seit Grub 2.06 auf etwa hundert eigene Patches verzichten konnte.

(tiw)