Seit Jahren ist der „Grand Unified Bootloader“ kurz „GRUB“ bzw. dessen Nachfolger GRUB2 bei den allermeisten Distributionen der Standard-Bootloader. Beide funktionieren sehr gut, wirken aber in Zeitalter von UEFI und auf normalen PCs, die nur von Festplatte booten, irgendwie aus der Zeit gefallen. Während GRUB Version 1 noch relativ übersichtlich und einfach zu konfigurieren war, benötigt man bei GRUB2 schon fast ein Hochschulstudium um durchzublicken.
PCs mit UEFI-Firmware benötigen keinen komplexen Bootloader mehr. Man kann die Firmware direkt den Kernel booten lassen. Ein dezidierter Bootloader ist in den meisten Fällen überflüssig und nur noch in Spezialfällen notwendig. Leider ist das Verfahren nicht ganz einfach umzusetzen, da man der Firmware die benötigten Kerneloptionen von Hand übergeben muss. Dazu können noch weitere Probleme kommen (Siehe z.B. ArchWiki – EFISTUB). Dazu kommt, dass bei einem Reset der Firmware alle Einträge verloren gehen und man mit einem nicht-bootfähigen System dasteht.
Es geht aber auch sehr viel einfacher:
Man benutzt einfach den, von systemd mitgelieferten, Bootloader „bootctl“. Der Loader ist kein neues Projekt, sondern hieß vor der Integrierung in systemd „gummiboot“ (Welcher wiederum nur als Referenzimplementierung gedacht war).
Installation von „bootctl“
[alert type=“warning“ icon-size=“normal“]Bitte die Anleitung einmal komplett durchlesen, bevor man sich darauf stürzt „bootctl“ einzusetzen![/alert]
Die Installation des Bootloaders ist sehr einfach (Ubuntu 16.04 und höher):
sudo apt-get purge grub* (Deinstalliert GRUB2 komplett)
sudo rm -r /boot/grub (GRUB2-Dateien aus dem boot-Verzeichnis/Partition löschen)
sudo efibootmgr -b 0000 -B (Entfernt den "ubuntu"-Eintrag aus der Firmare)
sudo bootctl install ("bootctl" in der Firmware hinterlegen)
[alert type=“danger“ icon-size=“normal“]Bitte setzt den Befehl „efibootmgr“ nur ein, wenn ihr 100% sicher seid, dass ihr dadurch nicht die Firmware-Einträge zerstört. Normalerweise ist der Ubuntu-Eintrag die Nummer 0000. Man sollte aber vor dem Löschen zur Sicherheit die Nummer überprüfen. Im Zweifelsfall lässt man den Eintrag in der Firmware und ändert im „BIOS-Setup“ die Reihenfolge von Hand und setzt den neuen Eintrag „Linux Boot Manager“ ganz nach vorne.[/alert]
Leider gibt es einen kleinen Makel:
Im Gegensatz zum Vorgänger „gummiboot“ bzw. dessen Paket in Ubuntu, installiert bzw. aktualisiert der Loader nicht automatisch die Kerneleinträge. Diese müssen leider von Hand angelegt werden. Aus diesem Grund habe ich die Dateien aus dem Paket „gummiboot“ extrahiert, welche diese Funktionalität unter „gummiboot“ bereitgestellt haben. Im Prinzip ist es nur eine kleine Konfigurationsdatei und ein kleines Shell-Skript, welche dafür sorgen, dass nach jedem Kernel bzw. Initrd-Update der Bootloader entsprechend konfiguriert wird. Hier mal der Link zur DEB-Datei:
Liste der Dateien im Paket:
/etc/default/bootctl (Konfigurationsdatei für den Bootloader. Hier werden die Kerneloptionen eingefügt) /etc/initramfs/post-update.d/zz-update-bootctl (Wird aufgerufen, wenn eine Initial-Ramdisk installiert bzw. aktualisiert wird). /etc/kernel/postinst.d/zz-update-bootctl (Wird bei einer Kernel-Installation aufgerufen) /etc/kernel/postrm.d/zz-update-bootctl (Wird bei einer Kernel-Deinstallation aufgerufen) /usr/sbin/update-bootctl (Das eigentliche Update-Skript. Kopiert den Kernel und die Initial-Ramdisk auf die EFI-Partition und legt im Loader die Einträge an).
Bei den meisten Systemen sollte es ausreichen das Paket zu installieren um den Bootloader fertig zu konfigurieren. Falls die EFI-Partition nicht unter „/boot/efi“ gemountet ist, muss man noch den Parameter „–path=PATH“ zum bootctl-Kommando hinzufügen und in der Datei „/etc/default/bootctl“ die Variable „BOOTCTL_EFI“ nach der Installation des Pakets entsprechend anpassen.
Warum das Ganze?
Wie schon am Anfang angesprochen, ist „bootctl“ deutlich einfacher aufgebaut als GRUB2. Es gibt im Grunde nur zwei Dateien die man bearbeiten muss, um den Loader zu konfigurieren. Dazu kommt, dass der Loader keine Probleme mit verschiedenen root-Dateisystemen hat. Auf meinem Desktop-PC liegt „root“ auf einem XFS-Dateisystem und ich musste meine „boot“-Partition explizit auf ein „ext4“-Dateisystem legen damit GRUB2 das System überhaupt booten konnte (Getestet unter Ubuntu 16.04, 16.10, Debian Testing). Eigentlich sollte GRUB2 mit XFS umgehen können, aber egal was ich versucht habe, es hat nicht funktioniert.
„bootctl“ sind die Dateisysteme vollkommen egal, da der Loader und die Kerneldateien immer auf der EFI-Partition liegen und ersterer nur dafür sorgt, dass der Kernel direkt von der Firmware geladen wird. Das heißt man kann grundsätzlich jedes Dateisystem als „root“-Partition einsetzen, solange der Kernel und die Initial-Ramdisk damit umgehen können. Bei Grub muss man sich daran orientieren, was dieses selbst an Dateisystemen unterstützt.
Bei mir bootet DEVUAN ASCII mit grub von einem LUKS verschlüsseltem lvm mit xfs. (Also ohne unverschlüsselte boot Partition.) Das geht über den Standard Debian Installer, den man manuell partitioniert und vor der grub Installation abbricht. Dann mounte ich das Installationsverzeichnis als chroot und ziehe aptitude und grub nach. Dann noch flux die /etc/default/grub angepasst mit Optionen für LVM, XFS und cryptomount (die variieren ja nach grub Version!) und schon liegen auf dem Rechner nur noch LUKS Partitionen als PVs für VGs die jede Menge LVs enthalten, die mit ganz eingeschränkter Funktionalität gemountet werden… (Vgl. sehr altes securing Debian).
Ginge das auch mit bootctl?
Bei Devuan nein, da bootctl ein Bestandteil von des systemd-Pakets ist:
https://packages.debian.org/search?searchon=contents&keywords=bootctl&mode=path&suite=stable&arch=any
Grundsätzlich kann man aber auch das Paket „gummiboot“ aus „oldstable“ nehmen. „bootctl“ ist nichts anderes, nur eben eines der Tools von systemd. Ob sich der Aufwand bei deinem Setup überhaupt lohnt, ist aber fraglich.
Wie kann Grub von einer verschlüsselten Partition das Kernelimage finden und booten? Irgendwo muss das Kernelimage ja liegen.
Wie grub das alles hinkriegt ist „straight forward“. Grub bietet mit der Option cryptomount = y (oder 1) je nach Version – … die Möglichkeit zu einem LUKS Aufruf aus grub heraus. D.h. grub startet einen kleine stub mit einem hässlichen grub prompt und will ein LUKS Password für die zu bootende Partition. Wenn der stub das richtige Password hat, dann startet er den eigentlichen grub Prozess auf der LUKS partition. Die grub module LVM und xfs laden dann, wenn grub den grub Auswahlbildschirm präsentiert die entsprechenden Kernel Module nach. Dann kann grub über den geladenen Kernel vernünftig booten.
Wie macht man das mit gummiboot? (Alias systemd-boot ) Geht das überhaupt?
M.E.ist gummiboot als „Bootmanager light“ angetreten. Klein, leicht mit wenig Features.
Da bootctl immer zusammen mit den unverschlüsselten Kernel-Images auf der EFI-Partition liegt, gibt es dieses Feature einfach nicht. Eine Möglichkeit ein ähnliches Szenario umzusetzen, ist die Verwendung von selbsterstellten Zertifikaten für SecureBoot und die Verwendung eines selbst-signierten Bootloaders und Kernels:
http://dannyvanheumen.nl/post/secure-boot-in-fedora/
Die Risikoabwägung „unverschlüsseltes Kernel-Image auf der EFI-Partition“ vs. grub-stub (den man natürlich auch per „evil maid“ Angriff manipulieren kann) gewinnt bei mir grub. Obwohl grub leider auch netzwerkfähig ist…
Bei dem SecureBoot Konzept hat sich bis heute bei mir noch keine Erkenntnis eingeschlichen, wie damit in der Praxis ein Sicherheitsvorteil für den Nutzer zu realisieren ist.
Wenn ich einen nach dannyvanheumen „abgesicherten“ Laptop manipulieren will, dann schalte ich einfach im UEFI BIOS „SecureBoot“ ab – oder noch fieser ich bringe meinen eigenen Kernel mit meinen eigenen Key mit. I.d.R. wird der Anwender nicht vor jedem Booten nach den BIOS Einstellungen schauen wollen. Zumal es reicht, wenn er einmal den neuen Kernel ohne „SecureBoot“ bootet um sein System so zu kompromittieren, dass der Angreifer danach den alten Zustand wieder herstellen kann.
IMHO ist SecureBoot eine Lösung für ein nicht existentes Problem.
„bei einem Reset der Firmware alle Einträge verloren gehen und man mit einem nicht-bootfähigen System dasteht.“
deshalb vorsorgen: pack refind.efi auf ne FAT SD-Karte mach ein entry dafür, und zack bootet alles was es gibt.
rEFInd ist das neue Gujin !
Kann man sich bei der Verwendung eines bootctl sparen, da dessen Einstellungen auf der EFI-Partition liegen. Und dessen Binary kann man per UEFI-Shell einfach starten.
bootctl = Gummiboot taucht als rotes Gummiboot (Boot Eintrag) in rEFInd auf.
Im UEFI hat man dann die Auswahl, ob man refind oder Gummiboot nach oben stellt, also bootet.
Möchte denjenigen sehen, der nicht refind bevorzugt, weil refind eben viel mehr kann als Gummiboot = sd-boot.
Okay, das Gummiboot ist immer schon dabei in Linux, aber refind bietet viel mehr automatische Optionen. „einfach per shell starten“ ?? Das ist bereits zu viel Arbeit für refind user, wozu die unnütze Tipperei ?
Das Gummiboot ist lediglich als fallback sinnvoll, speziell für Leute, die ihre grub.cfg mit EDLIN.EXE in DOSBOX editieren.
Und für Leute, die einfach nur ein oder zwei Betriebssysteme booten wollen, vollkommen überfrachtet. Gummiboot/bootctl tut einfach seinen Dienst und konfigurieren muss ich da auch nichts.
Gummiboot tut nur den Dienst für Linuxe, welche darauf vorbereitet sind, also nicht jedes.
Auf rEFInd braucht man kein Linux vorbereiten – es bereitet sich selbst vor und funktioniert immer. Gummi-bootctl interessiert viele Leute nicht, weil es meist ERROR anzeigt.
1. Gummiboot ist für UEFI-Systeme gedacht. Nicht mehr, nicht weniger.
2. (Nahezu) Jede Linux-Distribution hat EFISTUB zum direkten Booten des Kernels durch die (U)EFI-Firmware aktiviert. Da braucht man also nichts vorbereiten.
3. Ich habe Gummiboot auf mehreren Systemen im Einsatz und ein „ERROR“ ist mir noch nicht begegnet.
„ein „ERROR“ ist mir noch nicht begegnet.“
Ich weiß, ich bin der einzige, der je ERROR sah. Den Spruch hab ich schon tausend mal gehört. Null mal geglaubt.
Beim Booten ist mir mit Gummiboot noch kein Error begegnet. Nur beim Einrichten, wenn das Tool die gemountete EFI-Partition nicht selbständig bestimmen kann. Dann muss man halt den Pfad über den Parameter „–path“ einmalig mit angegeben.