LinuxBoot bringt durch einen Linux-Kernel anstelle von UEFI mehr Kontrolle über den Bootprozess.

Wer als Linux-Anwender glaubt, die volle Kontrolle über sein System zu besitzen, der irrt – zumindest derzeit noch. Das macht eine Präsentation von Google-Sicherheitsexperten [1] um Ronald Minnich und Tremell Hudson klar, die versuchen, im Rahmen des Projekts NERF (Non-Extensible Reduced Firmware) UEFI fast komplett durch einen kleinen Linux-Kernel samt Initramfs zu ersetzen. Das soll nicht nur den Bootvorgang beschleunigen, sondern auch mehrere Kernel entfernen, die ohne Kontrolle des Anwenders während des Hochfahrens des Rechners laden. Gleiches gilt für die geschlossene, nicht vertrauenswürdige und fehlerbehaftete Intel Management Engine (IME) [2].

Eines der Hauptziele der NERF-Entwickler besteht darin, so viel wie möglich von UEFI und IME zu entfernen oder zu deaktivieren (Abbildung 1). Völlig dürfte das nicht gelingen, aber es besteht zumindest die Chance, große Teile zu ersetzen. Jeder moderne Intel-Prozessor bringt eine Management Engine mit, die beim Booten, zur Laufzeit und selbst im Schlafmodus läuft. Da die IME über die permanente 5V-Versorgung aus dem Netzteil gespeist wird, muss der Rechner dazu nicht einmal eingeschaltet sein.

Abbildung 1: Das Unified Extensible Firmware Interface (UEFI) sitzt zwischen der Firmware und dem eigentlichen Betriebssystem.

Binärblob IME

Die IME setzt sich aus einem Microcontroller und einer proprietären Firmware zusammen, die sich je nach CPU und OEM unterscheidet. Die Firmware liegt in Form einer von Intel kryptografisch signierten, jedoch nicht durchgängig dokumentierten Binärdatei vor. Somit führt die CPU im Rahmen der IME unbekannten und nicht nachprüfbaren Code aus, auf die der Benutzer keinerlei Einfluss besitzt. Das betrifft die Intel-Core-Serien i3, i5, i7 sowie die Xeon-Prozessorfamilien.

In frühen Versionen saß der Microcontroller im Netzwerkchip, dann in der Northbridge des Chipsatzes; mit Intels Core-i-Architektur wurde er Teil der CPU. Der Controller der IME arbeitet dabei völlig unabhängig von der CPU und stellt einen Computer im Computer dar. Die IME verwendet ihr eigenes Betriebssystem und verfügt über Flash-Speicher, einen internen Bus, einen Webserver und eine Kryptografie-Engine. Zudem erhält die IME Zugriff auf den Hauptspeicher des Systems und – über den Intel Gigabit Ethernet Controller – auch auf das Netzwerk.

Nicht nur die Free Software Foundation (FSF) [3] hat sich gegen dieses zusätzliche proprietäre Sub-Betriebssystem gewandt, sondern auch die Electronic Frontier Foundation (EFF) [4] und Sicherheitsexperten wie Matthew Garrett [5]. Neben der Tatsache, dass die IME ein nicht zu kontrollierendes System im System darstellt, stellt sie aufgrund von mehrfach darin gefundenen Fehlern eine Sicherheitslücke dar.

Um die Schwachstellen zu beheben, bedarf es eines Firmware-Upgrades, das viele Systeme erfahrungsgemäß niemals erreicht. Findet ein Angreifer einen Weg, eine solche Lücke erfolgreich auszunutzen, hat er volle Kontrolle über das System – der Anwender würde davon vermutlich nichts merken. Dieses Szenario wies erst kürzlich Intels ehemaliger Sicherheitschef mit der Abwandlung einer Spectre-1-Attacke nach [6].

Die IME erlangt diesen allumfassenden Zugriff dadurch, dass sie im x86-Ring-Modell (Abbildung 2) im niedrigsten Ring -3 läuft und somit noch zwei Ebenen unter UEFI steht. Im Ring residiert der System Management Mode (SMM) [7]. Auch AMD gilt in dieser Hinsicht als keine sichere Bank: Die neuen Ryzen-Chips enthalten mit dem “AMD Platform Security Process” (PSP) [8] ebenfalls ein “schwarzes Loch”. Hier soll Linux dazu beitragen, die Kontrolle über den Boot-Prozess zurückzugewinnen.

Abbildung 2: Im üblichen Ringmodell der x86-Architektur ist Ring 0 mit dem Kernel der am höchsten privilegierte Ring. Darunter liegen, mit höheren Privilegien versehen, Ring -2 mit den System Management Mode (SMM) und Ring -3 mit der Intel Management Engine (IME).

Wer hat’s erfunden?

Die Idee zu LinuxBoot ist keineswegs neu. Bereits 1999 rief Robert Minnich am Los Alamos National Laboratory das Projekt LinuxBIOS ins Leben, das 2008 in Coreboot [9] aufging (Abbildung 3). Dabei wurde LinuxBIOS minimiert und verlor wegen immer kleinerer Flash-Speicher seine Linux-Anteile. Übrig blieb das generische Mainboard-Initialisierungswerkzeug Coreboot, das nach der Initialisierung eine “Payload” startet, die den Rest des Boot-Vorgangs übernimmt. Diese Payload enthält heute oft Grub 2, könnte aber auch aus einem anderen Bootloader oder einem Linux-Kernel bestehen.

Abbildung 3: Bereits seit 1999 ersetzt LinuxBIOS auf einigen Supercomputern und eingebetteten Geräten das herkömmliche BIOS.

LinuxBoot (Abbildung 4) ging 2017 aus dem Google-Projekt NERF hervor, Anfang 2018 nahm es die Linux Foundation unter ihre Fittiche [10]. Das Projekt wird unter anderem von Google, Facebook, Horizon Computing Solutions, 9elements und Two Sigma unterstützt. LinuxBoot knüpft an die Ideen von LinuxBIOS an, das vor allem auf Supercomputern und eingebetteten Geräten lief. Das Konzept, obskure Firmware wie IME oder die UEFI-DXE-Phase, in der der Großteil der Systeminitialisierung stattfindet, durch einen Linux-Kernel zur Initialisierung zu ersetzen, soll erweitert und auf heutige Desktops, Notebooks und Server zugeschnitten werden.

Abbildung 4: Während LinuxBIOS nicht für den Desktop konzipiert war, zielt LinuxBoot auch dort auf die Verdrängung von proprietärer Firmware und UEFI.

Am Anfang steht die Firmware

Die Firmware auf den meisten heutigen Computersystemen dient dazu, die Hardware in einen Zustand zu versetzen, der es einem Betriebssystem ermöglicht, zu übernehmen. Linux-basierte Systeme verfügen in der Regel über eine Firmware-Komponente, die die Hardware initialisiert, bevor der Linux-Kernel selbst startet. Diese Phase umfasst gemeinhin die Initialisierung von RAM-, Speicher- und Netzwerkschnittstellen sowie die Ausführung sicherheitsrelevanter Funktionen vor dem Start von Linux. Als die Entwicklung von LinuxBIOS 1999 begann, umfasste diese vorbereitende Phase gerade einmal rund 100 Anweisungen, heute aber bereits mehr als eine Milliarde.

Moderne Firmware besteht grob gesagt aus zwei Hauptteilen: einer frühen Phase zur Hardware-Initialisierung und einer späteren mit dem Laden des Betriebssystems. Die Firmware, die früher in ein 8-KByte-ROM passte, enthält jetzt ein komplettes Betriebssystem, das zum Booten eines anderen Betriebssystems dient, und hört nicht immer nach dessen Booten zu laufen auf. Das trifft beispielsweise auf Intels IME zu.

LinuxBoot will die späten Phasen durch einen Linux-Kernel und ein Initramfs [11] ersetzen, die das Laden und Ausführen der nächsten Phase übernehmen. Den in LinuxBoot enthaltenen Linux-Kernel bezeichnet man als “Boot-Kernel”. Das soll ihn vom eigentlichen System-Kernel unterscheiden, der nicht unbedingt ein Linux-Kernel sein muss (Abbildung 5).

Abbildung 5: Der Bootprozess bezeichnet die verschiedenen Komponenten und Prozesse bei UEFI, Coreboot und LinuxBoot unterschiedlich.

Erleichterung

Das Bündeln eines Linux-Kernels mit der Firmware vereinfacht die frühe Phase des Boot-Vorgangs gleich in zweierlei Hinsicht. Es entfällt die Notwendigkeit, dass die Firmware Treiber für die ständig wachsende Zahl an Boot-Medien, Netzwerkschnittstellen und Peripheriegeräten mitbringt – die liefert der Kernel. Zudem muss die Firmware auch keine Werkzeuge integrieren, um Aufgaben wie den Zugriff auf verschlüsselte Partitionen zu bewältigen. Auch hier gilt: Der Kernel bringt alles Nötige bereits mit.

Für ein System mit UEFI-Firmware braucht es für Dinge wie SMM oder das Setup der ACPI-Tabelle zwingend die PEI (Pre-EFI Initialization) und eine kleine Anzahl von DXE-Modulen (Driver eXecution Environment). Mit LinuxBoot fällt hingegen die Notwendigkeit für die meisten DXE-Module weg, da die Initialisierung der Peripherie über Linux-Treiber erfolgt. Auch die BDS-Phase (Boot Device Selection) und die “Ramstage” von Coreboot, die verschiedene Peripheriegeräte initialisiert, lassen sich stark vereinfachen oder gleich ganz überspringen (Abbildung 6).

Abbildung 6: LinuxBoot wird UEFI nicht völlig ersetzen können: Ohne die Pre-EFI Initialization (UEFI-PEI) würde der Rechner nach 30 Minuten aus Sicherheitsgründen herunterfahren.

RAS-Funktionen

Zusätzlich gibt es Firmware, die Fehler und andere Hardwareereignisse behandelt. Solche Komponenten nennt man im Allgemeinen RAS-Features (Reliability, Availability and Serviceability) [12]. Die Implementierung von RAS-Funktionen erfolgt oft in Form hochpriorisierter, hochprivilegierter Interrupt-Routinen, die außerhalb des Kontexts des Betriebssystems laufen. Das passiert im System Management Mode. Da das die Sicherheit des Systems betrifft, soll LinuxBoot einige der RAS-Funktionen übernehmen [13].

Am Rande sei an dieser Stelle der Vollständigkeit halber auf das in Go geschriebene U-Root [14] hingewiesen, das innerhalb des LinuxBoot-Projekts entwickelt wird. Dabei handelt es sich um ein universelles Rootfs, dessen Initramfs mit nur wenigen Toolchain-Binärdateien gebündelt, zur Laufzeit erstellt werden kann. Das ermöglicht Echtzeit-Debugging auf Systemen, ohne dass man die Firmware neu kompilieren oder flashen muss. So lässt sich schwer reproduzierbaren Fehlern leichter auf die Spur kommen. Zur besseren Einordnung: NERF entspricht LinuxBoot mit U-Root als Initramfs.

Server profitieren mehr

Zwar kommt LinuxBoot auch dem Desktop-Anwender zugute, der mehr Kontrolle über den Boot-Vorgang seines Computersystems erlangen möchte. Am meisten profitieren aber Unternehmen und Institutionen mit einer Vielzahl an Servern von einem Linux-Boot-System (Abbildung 7). Das Ersetzen von meist proprietärem Firmware-Code durch Linux ermöglicht es den Entwicklern im Unternehmen, den Boot-Vorgang, die Wartung und den Support der Server zu optimieren und zu kontrollieren. Hinzu kommt, dass der freie Quellcode eine wesentliche Erleichterung darstellt, wenn es darum geht, Probleme hinsichtlich des Bootens zu verfolgen und zu lösen.

Abbildung 7: LinuxBoot kann den Systemkern sowohl von eingebauten oder per USB angebundenen Festplatten auch über das Netzwerk und die Cloud laden.

Fazit und Ausblick

Durch Linux-Bootcode, der einen guten Zugriff auf Hardwareressourcen bietet und Sicherheitsrichtlinien aufstellt, erhalten Anwender Transparenz, Nachvollziehbarkeit und Reproduzierbarkeit. Gerade in Unternehmen ist es heute zudem enorm wichtig, die Sicherheit unter eigene Kontrolle zu stellen. Linux bietet dazu robusten, gut getesteten und gepflegten Code, der offenliegt und aktiv entwickelt wird. LinuxBoot konzentriert sich zwar vordergründig darauf, Linux als Zielbetriebssystem zu unterstützen, besitzt aber das Potenzial, auch andere Betriebssysteme zu booten.

Wann man mit den ersten anwendbaren Ergebnissen für Linux-Nutzer rechnen darf, steht derzeit noch nicht fest. Noch im zweiten Quartal 2018 soll es erste Server der Open Compute Platform [15] mit LinuxBoot geben. Klar ist schon jetzt, dass es noch viel Arbeit gibt und es Jahre dauern wird, möglichst viele Teile von UEFI und der Intel-ME zu eliminieren.