© Viacheslav Nikolaienko, 123RF

Mit Coreboot bauen Entwickler Firmware-Abbilder für Hardware, die alle Vorteile von freier Software bieten und Rechner in der Regel schneller initialisieren als die mitgelieferte proprietäre Firmware. Der Artikel beleuchtet die Hintergründe und erklärt, welche Schwierigkeiten offener Firmware im Wege stehen.

Wer wartet nicht gern auf die Firmware-Aktualisierung gegen die Meltdown- und Spectre-Sicherheitslücken? Wer erfreut sich nicht an nervenaufreibenden Aktualisierungsprozeduren – im Rechenzentrum auf Hunderten Maschinen? Wer schreit nicht laut “Hurra”, weil sein Lenovo-Laptop nur noch bestimmte WLAN-Karten erlaubt, die auf einer Whitelist stehen? Und bei wem dauert der Firmware-Boot deutlich länger als der der gesamten Distribution? Alles bekannte Ärgernisse, die sich mit einer Firmware unter freier Lizenz umgehen ließen. Doch das ist nicht so einfach.

Auf freier Wildbahn

Coreboot [1] dürfte vielen Linux-Nutzern ein Begriff sein, vielleicht auch unter dem früheren Namen Linux-Bios (siehe Kasten “Das Coreboot-Projekt”). Die wenigsten nutzen die freie Firmware jedoch. Ein Hauptgrund dürfte sein, dass Hersteller Coreboot kaum standardmäßig ausliefern. Eine Ausnahme bilden Googles Chromebooks und -boxes [2], die Geräte von PC-Engines [3] und seit einiger Zeit die Systeme von Purism [4].

Die vermeintlich aufwändigere Installation einer alternativen Firmware und Bedenken, das Gerät eventuell kaputt zu machen, hält vermutlich die Mehrheit der Anwender davon ab, mit Coreboot zu experimentieren.

Der Artikel will diese Bedenken ein wenig zerstreuen und zeigen, welche Möglichkeiten in Coreboot stecken.

Was Coreboot macht

Mit Coreboot lassen sich Firmware-Abbilder für x86-, ARM- und Risc-V-Geräte erzeugen. Die Firmware soll die Hardware soweit vorbereiten, dass das Betriebssystem darauf laufen kann. Zu ihren Aufgaben gehört vor allem die Initialisierung sämtlicher Prozessoren und des Arbeitsspeichers.

Im Gegensatz zur üblichen Hersteller-Firmware verfolgt Coreboot das Ziel, nur so wenig Hardware wie möglich zu initialisieren und die Kontrolle anschließend so schnell wie möglich an die so genannte Payload zu übergeben. Dabei handelt es sich um ein beliebiges Programm, welches das Betriebssystem starten kann. Das kann ein Bios sein (etwa Seabios) oder ein UEFI (Tianocore). Zum Einsatz kommen kann dank der heutigen Flash-ROM-Chipgrößen auch ein Linux-Kernel mit einem Initrd-Abbild, der mit Hilfe von »kexec« den gewünschten Kernel startet.

Startvorgang

Im x86-Bereich springt der Prozessor zunächst zum Reset Vector, der als 16 Bytes vor dem Ende des Flash-ROM-Chips definiert ist. Die folgenden Instruktionen (Listing 1), auch zu finden unter [5], führt er dann direkt aus.

01         .section ".reset", "ax", %progbits
02         .code16
03 .globl _start
04 _start:
05         .byte  0xe9
06         .int   _start16bit - ( . + 2 )
07         /* Note: The above jump is hand coded to work around bugs in binutils.
08          * 5 byte are used for a 3 byte instruction.  This works because x86
09          * is little endian and allows us to use supported 32bit relocations
10          * instead of the weird 16 bit relocations that binutils does not
11          * handle consistently between versions because they are used so rarely.
12          */
13         .previous

Als Nächstes muss Coreboot den Arbeitsspeicher so schnell wie möglich einsatzbereit machen. Bis dahin nutzt es den Prozessorcache als Arbeitsspeicher (Cache as RAM). Zusätzlich muss es alle Prozessorkerne, den PCI-Bus und den Chipsatz initialisieren und konfigurieren. Im Anschluss dürfen bereits rudimentäre Programme laufen, was sich auch in den umfangreichen Menüs der proprietären Firmware widerspiegelt.

An die Maschinen!

Am besten lässt sich Coreboot an einem Beispiel demonstrieren. Der Emulator Qemu hilft dabei, ein Abbild für die Maschine »q35« zu bauen, einen Standard-PC von 2008 (Q35 und ICH9). Listing 2 zeigt die zugehörigen Befehle. Klappen würde das auch mit dem »pc« von 1996 (i440FX und PIIX), aber die Q35-Maschine ist aktueller und unterstützt AHCI. Zur Konfiguration kommt das vom Linux-Kernel bekannte Kconfig-Konfigurationssystem zum Einsatz.

01 sudo apt install build-essential git m4 bison flex zlib1g-dev gnat-7 libncurses5-dev python
02 git clone --recurse-submodules https://review.coreboot.org/coreboot.git
03 make crossgcc-i386 CPUS=$(nproc)
04 make menuconfig
05 make # V=1 für gesprächigen Modus
06 build/cbfstool build/coreboot.rom print
07 qemu-system-x86_64 -enable-kvm -M q35 -bios build/coreboot.rom -serial stdio -L /dev/shm

Über dessen »menuconfig«-Backend wählt der Admin im Menü unter »General Setup« die Option »Use CMOS for configuration values« aus. Dann ändert er unter »Mainboard« das Modell auf »QEMU x86 q35/ich9 (aka qemu -M q35, since v1.4)« und erhöht die Größe des Flash-ROM-Chips auf 8 MByte, um genug Platz zu schaffen (Abbildung 1). Auf aktueller Hardware kann die Größe auch 16 MByte betragen. Dann wählt er unter »Payload | Secondary Payload« alle Optionen aus.

Abbildung 1: Coreboot nutzt das vom Kernel bekannte Kconfig-Konfigurationssystem.

Anpassungen

Die Ausgabe des »cbfstool«, das die vorletzte Zeile von Listing 2 aufruft, steht in Abbildung 2. Es handelt sich dabei um das Coreboot-Dateisystem-Werkzeug. Zu sehen sind – unter anderem – die drei Dateien »bootblock«, »romstage« und »ramstage« sowie »fallback/payload«. Das letzte ist für x86-Geräte standardmäßig Seabios.

Abbildung 2: Das Coreboot-Dateisystem-Werkzeug »cbfstool« gibt bei seinem Aufruf verschiedene Informationen aus und listet unter anderem eine Fallback Payload auf.

Im Bootblock initialisiert Coreboot die serielle Konsole, in der Romstage den Arbeitsspeicher und in der Ramstage unter anderem die PCI-Geräte. Seabios zeigt zudem per Default alle Abbilder und ELF-Dateien im Verzeichnis »img/« zusätzlich im Startmenü an. Es ist Konvention, Konfigurationsdateien unter »etc/« zu speichern.

Die Grub-Payload verwendet standardmäßig »etc/grub.cfg« als Konfigurationsdatei und der folgende Befehl verringert die Wartezeit im Seabios-Startmenü von 5 Sekunden auf 1 Sekunde [6].

build/cbfstool build/coreboot.rom add-int  -i 1 -n etc/boot-menu-wait

Der Qemu-Befehl startet die Demo, und die Payload Seabios (Abbildung 3) zeigt nach dem Drücken von [Esc] das Startmenü an, in dem der Admin die einzelnen Geräte und Payloads auswählt. Gäbe es noch eine Platte mit MBR, würde auch diese zur Auswahl stehen.

Abbildung 3: Seabios bietet ein einfaches Startmenü, das sich nach dem Qemu-Startbefehl mit der [Esc]-Taste anzeigen lässt.

Wer alle Payloads einmal ausprobiert (Abbildungen 4 und 5) und sich dann den benutzten Platz all dieser Programme anschaut, stellt schnell fest, dass diese weniger als 300 KByte benötigen. An dieser Stelle lohnt es sich auch, das Kconfig-Menü zu erforschen und nach weiteren Möglichkeiten Ausschau zu halten.

Abbildung 4: Das Coreboot-UI CBUI nutzt Nuklear [7], um ein grafisches Menü anzuzeigen.

Abbildung 5: Die Payload »coreinfo« basiert auf Libpayload und zeigt Informationen zum System und zur Firmware an. Sie taucht ebenfalls als Eintrag in Seabios auf.

Wo ist was?

Im Quellcode-Verzeichnis »coreboot« gibt es zwei wichtige Ordner. Unter »src« liegen die Coreboot-spezifischen Dateien und unter »payloads« die Dateien für die Payloads. Unter »src/mainboard« befinden sich die nach den Herstellern benannten Verzeichnisse zu den einzelnen Platinen. Aus diesen Daten generiert sich auch die Wiki-Seite Supported Devices [8], die öffentlich einsehbar ist.

Aus x86-Zeiten warten hier noch die Verzeichnisse »src/cpu«, »src/northbridge« und »src/southbridge«. Heutzutage verwendet Coreboot jedoch sowohl für die x86- als auch die ARM-Architektur das Verzeichnis »src/soc«. Grund dafür ist, dass es kaum noch separate Chips für North- und Southbridge gibt.

Linux als Payload

Aktuelle Flash-ROM-Chips sind 8 MByte, manchmal sogar 16 MByte groß. So passt sogar ein kompletter Linux-Kernel mit Initrd darauf. Dabei agiert »kexec« als Bootloader, sodass kein Grub nötig ist. Die Vorteile liegen auf der Hand: Die Umgebung ist bekannt, sie erlaubt es, viele Anforderungen umzusetzen, und dank zahlreicher Nutzer sind die gröbsten Fehler gefunden und behoben.

Aus praktischer Sicht ist es auch sinnvoll, keinen Distributions-Kernel, sondern einen abgespeckten kleinen Linux-Kernel zu verwenden. Das verringert die Ladezeit und die Menge an Sicherheitsaktualisierungen.

Abbild erzeugen

Zunächst gilt es, ein Abbild für Debian zu erzeugen. Der Befehl »sudo apt install grml-debootstrap« installiert das Skript »grml-debootstrap« [9]. Über das Kommando

sudo grml-debootstrap --vmfile --vmsize 3G  --target /Path/qemu-debian.img -r sid

erzeugt Debootstrap das Debian-Betriebssystemabbild. Dies lässt sich mit Qemu über »qemu-system-x86_64 -enable-kvm -M q35 -m 1G -hda /Path/qemu-debian.img« starten. Da Qemu ein Emulator ist, muss es den Arbeitsspeicher zum Beispiel nicht initialisieren. Im nächsten Schritt kommt das selbst gebaute Firmware-Abbild zum Einsatz.

Linux im ROM

Wie anfänglich erwähnt, bietet die Installation des Linux-Kernels in den Flash-ROM-Chip einige interessante Anwendungsmöglichkeiten. Es gibt Projekte wie Heads [10] und U-root [11], die den schwierigen Part vereinfachen. Aber der Artikel will zur besseren Anschaulichkeit die einzelnen Schritte schildern.

Nach dem Herunterladen des Linux-Kernel-Quelltextes mit

git clone git://git.kernel.org/pub/scm/ linux/kernel/git/torvalds/linux.git

(ältere Kernelversionen funktionieren übrigens auch) benötigt der Admin eine Linux-Kernel-Konfiguration. Der Einfachheit halber greift er zu der aus dem Projekt Heads (»config/linux-qemu.config«, [12]) und kopiert sie als Datei ».config« in den Ordner mit dem eben heruntergeladenen Linux.

Zusätzlich benötigt er eine Laufzeitumgebung, die »kexec« enthält. Da das Bauen den Rahmen des Artikels sprengen würde, wartet ein mit Heads angefertigtes Abbild »initrd.cpio.xz« auf dem Listing-Server des Linux-Magazins [13]. Die Befehle aus Listing 3 passen den Pfad an und bauen die Treiber direkt in den Linux-Kernel ein, um das bereitgestellte Initrd einfach zu nutzen.

01 make olddefconfig
02 scripts/config --set-str INITRAMFS_SOURCE ""
03 scripts/config --enable ata
04 scripts/config --enable sata_ahci
05 scripts/config --disable sata_ahci_platform
06 scripts/config --enable e1000

Ein »make -j`nproc`« erzeugt das Linux-Kernel-Abbild, das der XZ-Algorithmus komprimiert, um die Größe klein zu halten. Das Packen und Entpacken klappt nicht so schnell wie mit dem LZ4-Algorithmus, dafür ist die Datei mit rund 3MByte sehr klein. Durch Optimieren der Konfiguration lässt sich die Größe noch weiter verringern, zudem verwendet Heads die ohnehin sehr Ressourcen-sparende Musl Libc [14].

Passt der Systemverwalter mit Hilfe von Kconfig den Abschnitt »Payload« an, indem er die Option »A Linux payload« auswählt, kann er ein neues Coreboot-Abbild mit dem Linux-Kernel als Payload bauen. Es klappt alternativ mit den folgenden Befehlen:

build/cbfstool build/coreboot.rom remove -n fallback/payloadbuild/cbfstool build/coreboot.rom add-payload -n fallback/payload -f bzImage -C "console=ttyS0,115200 console=tty0" -I initrd.cpio.xz

Dank der Linux-Kommandozeile landet die Ausgabe auch auf der seriellen Konsole. Jetzt lässt sich alles zusammen starten, wobei der Befehl auch gleich das Netzwerk zum Herunterladen von Daten konfiguriert [5]:

qemu-system-x86_64 -enable-kvm -M q35 -m 1G -bios build/coreboot.rom -serial stdio -L /dev/shm -hda /path/qemu-debian.img -net nic,vlan=0 -net tap,ifname=tap0,script=no,downscript=no

In der Initrd-Umgebung lässt der Admin das Debian-System dann über die folgenden Kommandos starten:

mount /dev/sda1 /mnt
cd /mnt/boot
kexec -l vmlinuz-4.16.0-1-amd64  --append="root=/dev/sda1 console=ttyS0,115200 console=tty0 iomem=relaxed" --initrd=initrd.img-4.16.0-1-amd64kexec -e

Das »iomem=relaxed« erlaubt den Zugriff auf MMIO-Speicherbereiche, den neuere Linux-Kernel strenger handhaben. Zeitstempel und Meldungen landen im Coreboot-Memory CBMEM.

Diese Initrd-Umgebung bietet am Ende alle Möglichkeiten, die ein Admin von seiner normalen Linux-Umgebung kennt. Hier stehen Treiber für WLAN, Netzwerkprotokolle und Dienste wie SSH wie auch eine Laufzeitumgebung für Skripte und Programme bereit.

01 ip link set enp0s2 up
02 ip addr add 10.0.1.2/24 dev enp0s2
03 ip route add default via 10.0.1.1 dev enp0s2
04 echo nameserver 1.1.1.1 | tee -a /etc/resolve.conf

Im Kernel von Debian ist das Modul zum Zugriff auf die im CBMEM-Arbeitsspeicherbereich gespeicherten Coreboot-Meldungen nicht aktiviert [15]. Deshalb erzeugt der Admin am besten noch das Programm »cbmem« aus dem Coreboot-Ordner »util«. Dazu konfiguriert er im ersten Schritt das Netzwerk (Listing 4). Im zweiten holt und übersetzt er das Programm »cbmem« mit den folgenden Befehlen:

git clone https://review.coreboot.org/coreboot.git
cd coreboot/util/cbmem
make && make install

Über »cbmem -c« lässt er sich nun die Coreboot-Meldungen anzeigen, die umfangreicher und verständlicher als die Nachrichten der Herstellerfirmware sind. Der Schalter »-t« ergänzt die Zeitstempel, was beim Verringern der Startzeit hilft. Der Schalter »-l« zeigt den Inhalt des CBMEM-Bereichs an.

Wie weiter?

Ein aktuelles Gerät kaufen, bei dem sich alle Funktionen der Hardware nutzen lassen, ohne Blobs zu verwenden, ist derzeit kaum möglich. ARM-Geräte kommen dieser Idee noch am nächsten, doch erweisen sich hier die Treiber für die Grafikgeräte als Hürde. Mit den freien Treibern lassen sich die Dekodier-Fähigkeiten der Hardware nicht verwenden. Die Prozessoren sind zwar schnell genug, um zum Beispiel Filme zu dekodieren, doch leidet die Laufzeit darunter.

Bei AMD-Geräten würden die Grafiktreiber Probleme bereiten. Der Radeon- und AMDGPU-Treiber benötigt das so genannte Atom-Bios, das nicht frei ist. Bei älteren Laptops, die keine Chromebooks sind, entsteht wiederum das Problem, dass die Firmware des Embedded Controllers nicht frei ist.

Aufgrund der Vielfalt ist der Einsatz von Coreboot auf echter Hardware komplizierter als der in Qemu. Am einfachsten machen es Geräte, die Coreboot bereits unterstützt. Googles Chromebooks erhalten hier die beste Qualitätssicherung. Für x86-Chromebooks und -boxes existieren auch Coreboot-Distributionen, die fertige Abbilder zum Herunterladen und Aufspielen anbieten ([16], [17]), für ARM-Geräte fehlen diese noch.

Um Flash-ROM-Chips [18] zu beschreiben, gibt es zwei Methoden. Bei unterstützten Zielgeräten darf das laufende Betriebssystem den Chip beschreiben. Fehlt dieser Support und sind zum Beispiel bestimmte Bereiche des Chips durch die Firmware schreibgeschützt, lässt sich ein externes Gerät verwenden.

Auf einen fest verlöteten Chip lässt sich über einen Adapter (Clip) per In-System-Programming zugreifen. Für das externe Gerät ist ein beliebiges System einsetzbar, welches das Protokoll (meist SPI) beherrscht. Beliebt sind der Raspberry Pi und Beaglebone Black.

Ist der Chip nur eingesteckt, ist es oft schneller, für ein paar Euro Ersatzchips zu bestellen oder aus alten Platinen zu sichern und Sicherungen zu speichern. Sollte etwas schiefgehen, tauscht man diese mit der Push-Pin-Methode einfach aus (Abbildung 6).

Abbildung 6: Beim Pinnwandnadel-Trick gilt es, die Nadel zu entfernen und den Rumpf auf den Chip zu kleben, um einen Griff zum einfachen Herausziehen zu erhalten.

Mit diesen Mitteln lässt sich somit auch immer die Herstellerfirmware zurückspielen. Die Zeit, um Coreboot auf noch nicht unterstützter Hardware zum Laufen zu bringen, variiert. Sie hängt davon ab, ob Coreboot bestimmte Komponenten bereits unterstützt, namentlich den SoC oder den Super-IO-Chip. Bei älteren Geräten ist das häufig der Fall. Es gibt sogar ein Skript namens »autoport«, das Systeme mit Intel Sandy und Ivy Bridge korrekt konfiguriert, sodass das System danach in der Regel startet.

Ausblick

Ein Wermutstropfen bleibt aber: Selbst dann, wenn Anwender Coreboot einsetzen, erhalten sie nicht die komplette Kontrolle über ihr System. Denn auf den in den letzten Jahren ergänzten Hilfsprozessoren laufen nach Einschätzung von Google-Mitarbeiter Ron Minnich zweieinhalb Kernel mit höheren Rechten vor dem Linux-Kernel (Tabelle 1).

Weil das die wenigstens Benutzer wissen und verstehen, gibt es in diesem Bereich wenig Druck und Fragen an die Hersteller. Um aber wirklich volle Kontrolle über ein gekauftes System zu haben, ist eine freie Firmware unumgänglich.

Mit Coreboot gibt es also inzwischen vor allem für x86- und ARM-Geräte eine zum Teil schon produktiv eingesetzte Alternative. Die Nutzer haben die Möglichkeit, diese Hersteller zu unterstützen oder sogar selber Support für bestimmte Hardware zu ergänzen. Eine eigene Veranstaltung, die Open Source Firmware Conference (OSFC, [19]), will im September in Erlangen alle freien Firmware-Projekte zusammenbringen.