Wenn Red Hat seinen Willen durchsetzt – was zum Leidwesen vieler Linux-Anwender oft genug der Fall ist, werden wir in absehbarer Zukunft nicht mehr mit GRUB oder einem anderen externen Bootloader booten, sondern mit dem Kernel selbst.
Vordenker
Die Idee ist nicht ganz neu, Lennart Poettering kam damit bereits vor fast zwei Jahren um die Ecke. Mit Fedora 40 vom Frühjahr sind die dort vorgeschlagenen Unified Kernel Images (UKIs) nachrüstbar. Ein Vortrag von Red Hats Marta Lewandowska auf der kürzlich zu Ende gegangenen DEVCONF.cz erläutert den derzeitigen Stand der Dinge. Ein Blogeintrag enthüllt weitere Details.
Warum kein Bootloader mehr?
In den mehr als 20 Jahren, in denen ich Linux nutze, haben hauptsächlich Lilo und GRUB den Boot-Prozess bestimmt, in jüngerer Zeit kam noch systemd-boot hinzu. In den letzten zumindest zehn Jahren dominiert GRUB. Aber GRUB ist behäbig, überladen und fehleranfällig. Das macht die Software schwer zu pflegen.
Booten per EFISTUB
Deshalb soll mit nmbl über den Kernel direkt gebootet werden. Das Booten per EFISTUB ist schon viel älter als Poetterings Idee und ist technisch gut erprobt und bietet einige Vorteile. Der Linux-Kernel hat eine viel größere Entwicklerbasis als GRUB, was zu einer schnelleren Entwicklung von Funktionen und einer schnelleren Reaktion auf Sicherheitslücken führt.
Unified Kernel Image
Das Konzept von nmbl sieht vor, Unified Kernel Image (UKIs) zu verwenden, die neben einem UEFI Bootstub und dem Kernel selbst auch dessen Kommandozeile und das initramfs beinhalten. Die Vorteile sehen die Fedora-Entwickler in verbesserten Boot-Zeiten, schnellerer Auslieferung von neuen Funktionen oder Fehlerbereinigungen. Neue Features müssen nur noch einmal implementiert werden.
Per Shim signiert
Derzeit stellt das unsignierte initramfs die größte Sicherheitslücke im Secure Boot-Prozess dar. Wenn man den Kernel, initramfs und die Kernel-Befehlszeile in eine UKI packt und die zusammengesetzte Binärdatei signiert, erhöht sich die Sicherheit erheblich. Stand der Dinge derzeit ist ein Proof of Concept, das derzeit unter UEFI (x86_64) funktioniert. Derzeit werden zwei Implementierungen von nmbl gebaut, die entweder den kexec-Pfad (der einen anderen Kernel ausführt als den, mit dem nmbl gebaut wurde) oder switch-root (der denselben Kernel verwendet und daher nur vom frühen Userspace zum echten Root-Dateisystem wechseln muss) verwenden. Diese beiden Implementierungen sind im folgenden Diagramm dargestellt:
Unterstützte Funktionen
Anfänglich wollen die Entwickler sowohl das Design von GRUB sowie seine Konfigurationsdateien, einschließlich der Verwendung der Bootloader-Spezifikation (BLS) erhalten. In der Folge sollen weitere, derzeit von GRUB unterstützt Anwendungsfälle implementiert werden:
- Netzwerk-Boot: http(s), PXE/tftp
- Booten von Netzwerkspeicher: NVMe über Netzwerk, iSCSI usw.
- TPM-Unterstützung
- Unterstützung für verschlüsselte LUKS-Festplatten
- LVM
- Fallback
Wer mehr über den Linux-Boot-Prozess erfahren möchte, dem sei ein ausführlicher Artikel im Arch Wiki empfohlen.
Die Entwicklung geht klar zu Unified Kernel Images, weil damit Secure Boot und Measured Boot einfacher zu implementieren sind. Zu wünschen wäre natürlich eine weitere Verbreitung freier EFI-Systeme wie Coreboot und der Aufbau von freien Schlüsselinfrastrukturen.
Grub ist mittlerweile einfach zu träge, siehe z.B. die Integration von LUKS2. Dann ist es auch kein Wunder dass man sich nach Alternativen umschaut.
EFISTUB mit UKI und Secure Boot funktioniert übrigens auch auf non-systemd-Distros, inkl. LUKS- und TPM2-Unterstützung.
Solang das nicht funktioniert, werde ich mich mit nmbl nicht beschäftigen müssen.
Nach meinem Kenntnisstand wird das bereits per TPM2 unterstützt.
Generell mag ich UEFI auch nicht. Dennoch muss man es akzeptieren, besser als keine alternative booten zunkönnen. Rein aus security Sicht sollte der sicherheitsrelevante code so einfach und schlank wie möglich sein. In diesem Zusammenhang sind die Aktivitäten stark zu begrüßen. Zumal ein verschlüsseltes und mit secure boot geschütztes system heute Pflicht ist! Einige Distros haben da bei der geführten default Installation noch mächtig Lücken.
Jede Aktivität dieses zu verbessern ist meiner Meinung nach zu begrüßen.
“Wenn man den Kernel, initramfs und die Kernel-Befehlszeile in eine UKI packt und die zusammengesetzte Binärdatei signiert,….”
Wer signiert? Und wer kann dann nicht mehr, ohne die Zustimmung von wem seinen PC starten? Und weshalb ist UEFI noch keine freie Software und wer signiert hier.
Mir kommt dieses Anliegen wie ein Attentat auf freie Software vor.
Man will das Booten Vereinheitlichen und es danach weg-signieren.
Auf diese Weise wird dann alles sehr, sehr, sehr viel sicher werden. 😉
Sagt wer?
Microsoft!
Sicherheit durch Obsoleszenz und die Monopolisierung.
Du signierst das gegebenenfalls selbst per sbsigntool.
Man braucht nur einen Schalter im UEFI ausbauen und dann startet nur noch das OS, das zuvor von Microsoft signiert wurde.
Auf dem Schaubild ist es gut zu erkennen welche Rolle UEFI zukommt. UEFI -> verifies and loads shim
Mir ist es eigentlich egal wie ein PC bootet. EFISTUB ist auch nicht schlecht. Wenn die Diskussion aber um die Sicherheit beim Booten gehen sollte, dann würde ich erst einmal von Coreboot reden wollen und davon die intel-ME nicht mit starten zu lassen.
Das Verfahren wie es oben beschrieben ist, ins dagegen eher dazu geeignet, Signierung als Pflicht einzuführen und dann später mittels UEFI darüber zu regieren welches OS in Zukunft noch werkeln darf.
Das kommt mit so vor, wie jemand der einen Auftrag erteilt, sein Haus sicherer zu machen und sich am Ende darüber wundert, das er keinen Schlüssel dafür bekommen hat.
Wann wird Tuxdedo sein erstes Notebook mit coreboot ausliefern?
Wenn dieser Baustein frei ist, dann kann man sich gerne über den Rest vom Bootvorgang unterhalten, aber mit UEFI behalten andere den Schlüssel darüber in der Hand.
Werkelt FrameWork nicht an einer Maschine mit Coreboot?
Purism (Librem5) hat mMn bereits etwas mit Coreboot im Angebot und nicht zu vergessen: Nitrokey, mit seinen gepimpten Laptops.
Wollte oder hat System76 schon?
Bei dem ein oder anderen kann die ME auch bzw. ist deaktiviert.
Ist nicht do, dass es keine Möglichkeiten gäbe😁.
Purism, System76, Nitrokey, Nova Customs und Star Labs bieten Rechner mit Coreboot an, teilweise auch mit measured boot.
Na ja, sag ich ja. Aber Danke für die Bestätigung.
Glaub nicht, dass von Tuxedo da noch viel kommt.
War mir nicht bekannt aber gut zu wissen, vielen Dank für den Hinweis.
Leider wird es bei dem, m. M. nach realistisch beschriebenen Szenario von tux nix, der Masse an Linux-Anwendern bzw. potenziellen Anwendern wenig nützen.
Es gab einige Gespräche, die man teils noch im Internet von BigTech-Vertretern findet, die alles andere als ein offenes und freies OS und Applications möchten, da es ihren Bestrebungen entgegenläuft.
Solange Linux eine Randerscheinung bleibt wird es maximal toleriert aber ich vermute durch den enormen Vorstoß von Microsoft mit der AGB-Änderung zum 30.09.2023 und nun dem vermeintlichen Sicherheitsupdate KB5040427 mit Zwangsbeglückung von Co-Pilot wird Linux zwangsläufig wachsen.
Also das macht IMO keinen Sinn.
Zu erklären das GRUB schlecht wartbar wäre, und man dann ja deutlich mehr Entwickler hat. was besser ist.
Ja klar hat man dann mehr Entwickler, aber auch einen gigantischen Monolith wie den Linux Kernel.
Deswegen braucht es dann auch diese Entwickler.🤦♂️
Das macht es kein bisschen wartbarer oder Übersichtlicher.
In Grub kann man sich als Endanwender noch relativ schnell einarbeiten, wenn sowas dann direkt über den Kernel geht, braucht man wirklich erstmal (wie von Win Fanboys immer behauptet!) ein Linux Studium.
Und zum Schluss wird man dann immer abhängiger von Anderen wie bei Systemd jetzt schon, wo es wegen immer mehr Programmen die darauf zugreifen, ohne Systemd immer mehr zur Frickelei wird.
Sorry aber dann bin ich definitiv raus, und gehe entweder zu BSD oder einen richtigen Exoten (wie z.B. Haiku, was ich schon als Surfstation nutze!).
Weil einen Bevormundung und Anwender dumm halten, wie bei Windows mach ich sicher nie wieder mit, und wenn ich dafür Frickel muss, dann gleich einen richtigen Exoten.
Linux entwickelt sich meiner Meinung nach da in den letzten Jahren echt in die falsche Richtung.😒
Das der Linux Kernel es als Option erlaubt, finde ich okay. Warum auch nicht?
Das gefühlt jede zweite Distro den neuesten Schlangenölhypes hinterherrennt? Fragwürdig.
> In Grub kann man sich als Endanwender noch relativ schnell einarbeiten
Oder gleich was vernünftiges wie Refind nehmen. Das sucht in definierten Ordnern nach startbaren Dingen und listet die Fein auf. Einfach und gut als Endanwender.
Ganz nett. Aber doch nur sinnvoll wenn auf dem Gerät nur ein OS installiert ist, am besten monolith.
Der Text auf der zweiten Graphik neben menu ist entlavend. Nach dem Motto: “Du – du, lass die Finger vom System.”
Und was passiert bei mehreren OS und ‘nmbl reduction’ ?
Während des Bootvorgangs eine F Taste drücken um ins EFI zu kommen, dann die EFI Bootauswahl wählen und ein UKI auswählen.
Da sind meiner Meinung nach die bisherigen Bootmanager geeigneter.
Unter Debian 12 geht das mit Hilfe eines UKI-Images ziemlich einfach. Klar, das muss man zwar manuell machen aber aus eigener Erfahrung kann ich sagen, dass das mit einem über “Secure Boot” signierten UKI-Image, welches dann über ein TPM-Modul einen LUKS-Container entsperrt.
Grob gesagt installiert man Debian im “Expertenmodus” weil man nur so die Installation von GRUB direkt unterbinden kann. Während der Installation erstellt man eine 300 MB EFI-Partition und einen LUKS-Container. In den Container packe ich dann ein LVM mit /-Volume und Swap. Dann sagt man, dass man keinen Bootloader haben möchte.
Nachdem die Installation abgeschlossen ist, bootet man von einem anderem Live-Medium, bindet dort den LUKS-Container mit dem /-Volume und der EFI-Partition ein, chrootet sich in das Debian rein und installiert die Pakete “dracut”, “tpm2-tools” , “efibootmgr” und “systemd-boot-efi”. Erstmal konfiguriert man Dracut so, dass es ein UKI-Image generieren soll und dem Linux-Kernel die richtigen Boot-Parameter mit gibt und generiert dann ein UKI-Image unter “/boot/efi/”. Danach legt man mit dem “efibootmgr” das UKI-Image in den EFI-Variablen ab und startet dann den Rechner neu.
Hat man alles richtig gemacht, sollte man nun in der Lage sein, das Passwort für den LUKS-Container einzugeben und das System vollständig zu starten. Jetzt nimmt man sich aus einem Github-Repo das Programm “sbctl” und generiert damit die Schlüssel für “Secure Boot”, setzt sie in die Firmware und signiert das Image damit. Dann knipst man im BIOS “Secure Boot” an und setzt dann mit “systemd-cryptenroll” einen Token für dein LUKS-Container ins TPM-Modul und nun sollte, wenn man alles richtig gemacht hat, das System ohne Passwortabfrage starten. 😅
Auch die “Linux Mint Debian Edition” konnte ich so umbiegen, dass es dieser Vorlage entspricht. 😉
Das klingt ziemlich komplex.
Die ganze Prozedur sollte dann wohl eher der Installer komplett übernehmen können, sonst wird das den normaler User davon abschrecken, das System so aufzusetzen…
Ja, da stimme ich zu. Nur ein Linux-Freak kriegt das so hin. Diesen Weg hab ich auch nur durch mühsames ausprobieren gefunden. Beim ersten Mal hab ich knapp 15 Versuche gebraucht, bis mein System überhaubt starten konnte. Nach der Prozedur braucht man noch weitere Schritte, damit das auch “wasserdicht” bleibt. Z.B. sollte man noch die Datei “/etc/kernel/postinst.d/dracut” andern, damit beim Kernel-Update auch das UKI-Image wieder an der richtigen Stelle generiert wird und dann über “sbctl” erneut signiert wird. 😅
Ich hab das mit Alpine Linux hinbekommen, dazu gibt es eine gute Anleitung. Man verwendet efi-mmkeys um die eigenen Schlüssel zu generieren. Auf meinem ThinkPad habe ich die MS-Keys gelöscht und durch die eigenen ersetzt. Mittels kernel-hooks wird das UKI erstellt und automatisch signiert, funktioniert auch automatisiert nach einem Systemupgrade. Als Loader verwende ich den efi-stub-loader von gummiboot. Dann noch mit efibootmgr einen Booteintrag erstellen und fertig ist die Geschichte.
https://wiki.alpinelinux.org/wiki/UEFI_Secure_Boot
Das ist ja alles noch nicht fertig für den Anwender. Geht halt bereits für Enthusiasten.
So ähnlich habe ich das bei Tumbleweed auch gemacht. Wobei es dort eine gute Anleitung gibt.
Hallo !
Das klingt sehr interessant !
Hast du das irgendwo noch etwas ausführlicher zusammengeschrieben ?
Würd ich gern probieren,
lg,
KK
Tatsächlich noch nicht… Vielleicht kann ich das mal irgendwo niederschreiben. 🤔
Hey Ferdinand, bitte den Satz noch mal lesen, da fehlt der Kaffee 🙂
Danke, musste aus dem Haus ohne Zeit, noch mal drüber zu lesen.
Kleiner Typo: Botprozess