© pichai pipatkuldilok, 123RF
Das althergebrachte Bios hat Jahrzehnte auf dem Buckel und mit der schnellen Entwicklung bei PCs und Laptops nicht Schritt gehalten. Seine Aufgaben übernimmt als sein potenter Nachfolger UEFI und sorgt für mehr Funktionen, Komfort und Sicherheit.
Seit 1981 starten PCs mit Hilfe des Basic Input Output System, kurz: Bios. Seitdem haben zwar verschiedene Hersteller diese Firmware immer wieder erweitert, doch ist sie bis heute nicht 64-Bit-fähig und schwer anzupassen. Um diese Altlast abzulösen, hatte Intel bereits Ende der 1990er Jahre eine Initiative für die Entwicklung einer 64-Bit-Firmware gestartet. Diese Extensible-Firmware-Interface-Initiative (EFI) ging 2005 in dem Unified EFI Forum auf. In diesem Forum arbeiten neben Intel unter anderem auch AMD, Microsoft und HP mit. Das Forum spezifiziert UEFI und stellt Referenzimplementierungen zur Verfügung.
Das Unified Extensible Firmware Interface (UEFI) beschreibt die Schnittstelle zwischen der Firmware eines Computers und dem Betriebssystem. Die UEFI-Implementierung initialisiert die Hardwarekomponenten, um den Start des Betriebssystem vorzubereiten. Sie erfüllt damit die gleiche Aufgabe wie das Bios. UEFI unterstützt jedoch 64-Bit-Architekturen nativ, ermöglicht grafische Benutzeroberflächen und kann vor Schadsoftware schützen, indem es nur signierte Betriebssysteme zulässt (Secure Boot).
Bootphasen
Im Gegensatz zum Bios ist die UEFI-Firmware modular aufgebaut und erweiterbar. Wenn sie in Aktion tritt, durchläuft sie verschiedene Phasen in einer strengen Reihenfolge. Die Phasen zeigt Abbildung 1. Die erste heißt Security Phase (SEC). Der Name ist allerdings unglücklich gewählt, denn in die Phase fallen kaum sicherheitsrelevante Aktionen. Insbesondere prüft die UEFI-Firmware hier keinerlei Signaturen. Im Wesentlichen initialisiert diese Phase mit Hardware-spezifischem Code die CPU nach einem Reset. Den Code lädt die CPU dafür direkt vom Flash. RAM steht zu diesem Zeitpunkt noch nicht zur Verfügung. Stattdessen nutzt die UEFI-Firmware temporären Speicher, nämlich den CPU-Cache, als RAM. Die SEC-Phase übergibt Größe und Speicherort dieses temporären Speichers sowie optionale Information über die CPU an die Pre-EFI Phase.
Abbildung 1: Der UEFI-Bootprozess durchläuft eine Reihe von Phasen.
Die Pre-EFI Phase (PEI) initialisiert den Hauptspeicher sowie diejenigen Hardwarekomponenten, die für die nächsten Phasen unbedingt erforderlich sind. Zu diesem Zweck gibt es Pre-EFI Initialization Modules (PEIMs). Die PEIMs stellen sich untereinander APIs zur Verfügung (PEIM-to-PEIM Interface, PPI). Verantwortlich für das Laden und das Ausführen der PEIMs ist der PEIM-Dispatcher. Er untersucht, wovon die PEIMs abhängen, lädt sie in den nun verfügbaren Hauptspeicher und führt sie in einer bestimmten Reihenfolge aus.
Neben der Initialisierung grundlegender Hardwarekomponenten liest die UEFI-Firmware auch eine strukturierte Sammlung von Code und Daten, die sich Firmware Volume Location nennt. Sie ist typischerweise im Flashspeicher abgelegt und enthält unter anderem Gerätetreiber für die nächste Phase. Nachdem der Dispatcher die meisten erforderlichen PEIMs ausgeführt hat, sucht er abschließend den DXE IPL PEIM. Dieses letzte PEIM übergibt die Ausführung dann an die darauffolgende DXE-Phase.
In der Driver-Execution-Environment-Phase (DXE) kommt der größte Teil der erforderlichen Initialisierung des Systems an die Reihe. Ähnlich der PEI-Phase besitzt auch diese Phase einen Dispatcher. Er lädt DXE-Treiber aus der Firmware Volume Location und führt sie in der gewünschten Reihenfolge aus. Die DXE-Treiber initialisieren alle benötigten Hardwarekomponenten und registrieren oder nutzen Protokolle.
Als Protokoll bezeichnen die UEFI-Entwickler Abstraktionen einer Software, eines Geräts oder einer bestimmten Funktionalität, die andere Treiber oder UEFI-Applikationen verwenden können. Protokolle realisieren zum Beispiel die Textausgabe auf der Konsole oder den Zugriff auf PCI-Geräte.
Ist ein Protokoll ausschließlich verfügbar, bevor das Betriebssystem startet, spricht man von einem Boot-Service. Im Gegensatz dazu fallen Protokolle unter die Bezeichnung Runtime-Services, wenn man auf sie auch während der Laufzeit des Betriebssystems zugreifen kann.
Nachdem der Dispatcher alle Treiber geladen hat, geht es weiter mit der Boot Device Selection Phase. Die BDS-Phase führt den UEFI-Bootmanager aus. NVRAM-Variablen geben dem Bootmanager vor, welche UEFI-Applikationen zu starten sind. Das Betriebssystem kann diese Variablen durch einen Runtime-Service beeinflussen und so die UEFI-Applikationen festlegen, die auszuführen sind. Einige UEFI-Applikationen, beispielsweise Diagnose- oder Recovery-Applikationen, liefert der Hardwarehersteller häufig mit. Der Benutzer kann selbst weitere Applikationen ergänzen und in den Bootvorgang einbinden.
Eine besondere Applikation stellt der OS-Bootloader dar. Ihn lädt und startet das System typischerweise von der EFI System Partition (»/boot/efi«). Durch das Starten des OS-Bootloaders wechselt der Bootprozess in die Transient System Load Phase (TSL). Falls das System Secure Boot verwendet, würde hier dessen Signatur vor der Ausführung geprüft. Unsignierter Code wird dann nicht ausgeführt. Die TSL-Phase endet mit dem Aufruf der Funktion »ExitBootServices()«. Dieser Aufruf räumt den Arbeitsspeicher gründlich auf und belässt lediglich die speziell gekennzeichneten Schnittstellen im Arbeitsspeicher, die während der Laufzeit des Betriebssystems verfügbar sein sollen.
Nach dem Aufruf vom »ExitBootServices()« befindet sich das System in der Runtime Phase (RT), in der das Betriebssystem läuft, das seinerseits auf die UEFI-Runtime-Services zugreifen kann. Nach der Runtime-Phase tritt das System mit der Beendigung des Betriebssystems in die After-Life-Phase (AL) ein. Diese ist für einen geordneten Shutdown gedacht. Sie wird jedoch kaum genutzt.
UEFI-Runtime-Services und Variablen
UEFI-Runtime-Services sind UEFI-Funktionen, die während der Laufzeit des Betriebssystems nutzbar sind. Hierzu registriert sich ein UEFI-Treiber als Runtime-Service und trägt sich in die Runtime-Service-Tabelle ein. Während des Bootvorgangs bekommt das Betriebssystem diese Tabelle übergeben. Über die Tabelle hat das Betriebssystem zum Beispiel Zugriff auf die Real Time Clock, kann einen Plattform-Reset auslösen, auf Variablen im NVRAM zugreifen oder ein Firmware-Update anstoßen.
Während auf einem Linux-System die meisten Runtime-Services lediglich für Kerneltreiber erreichbar sind, wird der Zugriff auf die NVRAM-Variablen sowie die Firmware-Update-Funktion durch den Linux-Kernel in den Userspace exportiert. Der Linux-Kernel macht UEFI-Variablen über das UEFI Variable Filesystem (»efivarfs«) im Userspace zugänglich. Per UEFI gestartete Linux-Distributionen binden das Filesystem unter »/sys/firmware/efi/efivars« ein.
Alle vorhanden Variablen kann sich der Anwender durch »ls /sys/firmware/efi/efivars« auflisten lassen. UEFI-Variablen kann er wie normale Dateien lesen. Den Inhalt einer Variablen gibt der Befehl
cat /sys/firmware/efi/efivars/Variable
auf der Konsole aus. Die gespeicherten Informationen liegen dabei jedoch in einem maschinenlesbaren Format vor, wodurch die Ausgaben des Cat-Befehls oft kryptisch wirken.
Der Administrator darf diese Variablen wie eine normale Datei schreiben oder löschen. Das ist mitunter nicht ungefährlich. Früher konnte ein »rm -rf /« dazu führen, dass neben allen Dateien auf der Festplatte auch alle UEFI-Variablen gelöscht wurden. Einige fehlerhafte UEFI-Implementierungen erwarteten aber bestimmte Variablen. Wurden diese gelöscht, startete der Computer nicht mehr und der Admin musste das Mainboard zur Reparatur einschicken.
Aktuelle Linux-Kernel schützen daher die meisten Variablen durch das Immutable-Flag:
# lsattr PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c ----i-------------- PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8
Ein versehentliches Löschen oder Ändern ist somit ausgeschlossen. In der Praxis greift ein Benutzer nicht direkt über Befehle wie »cat« auf die Variablen zu. Er nutzt stattdessen Spezialprogramme wie den »efibootmgr«. Dieser erlaubt es einem Benutzer, die Gruppe der Bootvariablen zu bearbeiten.
Durch die Bootvariablen wird die Boot Device Selection Phase (BDS) gesteuert. Beginnt eine Variable mit »Boot000«, stellt sie einen Eintrag im UEFI-Bootmanager dar. Der Wert der Variablen gibt den Speicherort einer UEFI-Applikation an, die während der BDS-Phase startbar ist. Die Reihenfolge, in der die Applikationen zu starten sind, legt die Variable »BootOrder-GUID« fest. Das Programm »efibootmgr« verwaltet diese Variablen mittels der Kommandozeile. Der folgende Befehl zeigt die aktuelle Konfiguration der BDS-Phase an:
# efibootmgr --verbose BootCurrent: 0003 Timeout: 1 seconds BootOrder: 0003,0002 Boot0002 Hard Drive BBS(HD,,0x0) Boot0003* debian HD(1, GPT, cf2d93bb-3cd3-4903-9b7ccbfc697f7aae, 0x800, 0x1dc800)/File(\EFI\debian\grubx64.efi)..BO
In diesem Beispiel existieren zwei Einträge. Der Eintrag mit der Bezeichnung »debian« steht in der Bootreihenfolge ganz vorne und wird somit zuerst ausgeführt. Der Eintrag verweist auf die EFI System Partition (»/boot/efi«), auf der Grub abgelegt ist. Das System führt also in der BDS-Phase zunächst die UEFI-Implementierung von Grub aus. Grub wiederum startet den Linux-Kernel. Durch den »efibootmgr« lassen sich neue Bootvariablen hinzufügen oder die Bootreihenfolge verändern.
Während die Bootvariablen beliebig anpassbar sind, ist der Schreibzugriff auf andere Variablen beschränkt. Dazu zählen unter andrem die Variablen »PK« »KEK«, »DB« und »DBX«. Diese Variablen speichern die öffentlichen Schlüssel für die Signaturprüfung im Rahmen von Secure Boot.
Dürfte ein Angreifer diese Variablen beliebig ändern, könnte er auch Secure Boot umgehen oder ausschalten. Daher dürfen nur signierte Daten in diese Variablen gelangen. Die UEFI-Implementierung überprüft die Signatur der übergebenen öffentlichen Schlüssel und lässt den Schreibvorgang nur zu, wenn die Signatur vertrauenswürdig ist.
Update Capsule
Ein weiterer interessanter UEFI-Runtime-Service trägt den Namen Update Capsule. Das Betriebssystem kann mit diesem Service Datenblöcke an die UEFI-Firmware übergeben. Das Betriebssystem legt die Daten dazu im Arbeitsspeicher ab und teilt der Firmware den Speicherort über den Update-Capsule-Service mit. Anschließend wird ein System-Reset auslöst. Der Computer startet neu. UEFI greift jetzt auf den bereitgestellten Datenblock zu.
Der Service wird hauptsächlich dazu genutzt, Updates der UEFI-Firmware durchzuführen. Der Vorteil dieses Verfahren besteht darin, dass die Firmware den eigentlichen Updatevorgang übernehmen kann. Der Administrator benötigt kein proprietäres Tool, das meist nur unter Windows verfügbar ist.
Die einheitliche UEFI-Schnittstelle macht das Firmware-Update Betriebssystem-unabhängig. Bislang nutzt beispielsweise Microsoft dieses Verfahren, um Surface Tablets übers Windows-Update mit neuer Firmware zu versorgen. Auch Apple setzt dieses Verfahren bereits für bestimmte Macbooks ein. Linux-Benutzer können die Update-Funktion zurzeit nur in Verbindung mit wenigen Systemen nutzen. Neben Microsoft und Apple ist Dell der einzige größere Hardwarehersteller, der Firmware-Updates im Update-Capsule-Format anbietet.
Der Linux-Kernel exportiert die Update-Schnittstelle ähnlich den UEFI-Variablen über das Dateisystem. Das Verzeichnis»/sys/firmware/efi/esrt« beinhaltet die EFI System Resource Table (ESRT). Für jedes Gerät, das über die Update-Capsule-Schnittstelle aktualisiert werden kann, erzeugt der Kernel einen Eintrag. Das Tool »fwupdate« listet diese Geräte auf. Installiert wird das Tool mittels:
sudo apt-get install fwupdate
Eine Liste aller Update-Capsule-fähigen Geräte des Systems erzeugt der Befehl:
fwupdate --list
Sofern es für die aufgeführten Geräte eine Update-Capsule-kompatible Firmware gibt, lässt sich diese so installieren:
fwupdate --apply=guid-of-hardware firmware.cap
Die Funktionalität unterstützen bislang – wie schon gesagt – leider nur wenige Hersteller. Sie zeigt jedoch, welche Vorteile das standardisierte UEFI-Interface gegenüber proprietären Bios-Implementierungen bietet.
Eigener Code
Zum Entwickeln von UEFI-Applikationen dient das EFI Developer Kit II (EDK II). Es stellt die aktuelle Referenzimplementierung der UEFI-Spezifikation dar und wird von vielen Herstellern als Basis für eigene Firmware genutzt. Damit der Entwickler seinen Rechner zum Testen eigener Applikationen nicht ständig neu starten muss, arbeitet er am besten unter Qemu. Das EDK II enthält alles Nötige, um eine vollständige UEFI-Firmware zu generieren und unter Qemu zu starten.
Zunächst muss der Entwickler einige Abhängigkeiten installieren. Unter Ubuntu 16.04 gelingt das mit dem Befehl:
sudo apt-get install build-essential uuid-dev iasl git gcc-5 nasm
Die letzte Stable Release des EKD II bezieht er am einfachsten über Github:
mkdir ~/src cd ~/src git clone https://github.com/tianocore/edk2.git vUDK2017
Nach dem Download übersetzt er zunächst die Base Tools:
cd ~/src/vUDK2017 make -C BaseTools
Hat alles geklappt, ist das EDK einsatzfähig. Der Sourcecode ist in Paketen strukturiert. Wichtig sind die Pakete »MdeModulePkg« und »MdePkg«. Sie implementieren die eigentliche UEFI-Spezifikation. Der Code ist weitgehend Architektur-unabhängig. Um eine Firmware zu erzeugen, die auf einer bestimmten Plattform lauffähig ist, benötigt die Firmware jedoch plattformspezifischen Code. Für Qemu liefert das EDK diesen Code bereits mit. Das Paket Ovmf baut intern auf den Mde-Paketen auf und ergänzt die Qemu-spezifischen Teile.
Damit das Ovmf-Paket ein EDK erstellt, muss der Entwickler die Datei »~/src/vUDK2017/Conf/target.txt« anpassen. Als »ACTIVE_PLATFORM« legt er das Ovmf-Paket fest:
ACTIVE_PLATFORM = OvmfPkg/OvmfPkgX64.dsc
Zusätzlich muss er die Architektur und die genutzte Compiler-Toolchain anpassen. Auf einem x64-Ubuntu 16.04 verwendet er folgende Werte:
TARGET_ARCH= X64 TOOL_CHAIN_TAG= GCC5
Ist die Zielplattform festgelegt, startet er den erste Build-Vorgang:
source edksetup.sh build
Der Build dauert wenige Minuten und speichert die fertige Firmware in dem Verzeichnis »~/src/vUDK2017/Build/OvmfX64/DEBUG_GCC5/FV«.
Mit Qemu lässt sich die UEFI-Firmware auch testen. Die benötigten Firmwaredateien kopiert der Entwickler hierzu in ein neues Verzeichnis (Listing 1). Mit dem folgenden Befehl startet er eine virtuelle Maschine und führt die Firmware aus:
Listing 1
Kopieren der Firmwaredateien
01 mkdir ~/efibin 02 cd ~/efibin 03 cp ~/src/vUDK2017/Build/OvmfX64/DEBUG_GCC5/FV/OVMF_CODE.fd . 04 cp ~/src/vUDK2017/Build/OvmfX64/DEBUG_GCC5/FV/OVMF_VARS.fd .
Qemu-system-x86_64 -drive if=pflash,format=raw,file=OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd
Der ganze Vorgang war erfolgreich, wenn Qemu für kurze Zeit ein Logo mit dem Schriftzug »TianoCore« anzeigt und anschließend die UEFI-Shell startet (Abbildung 2).
Abbildung 2: Die UEFI-Shell ist gestartet.
Für erste Versuche mit eigenen UEFI-Applikationen, kann der Entwickler die Hello-World-Applikation des »MdeModule«-Moduls als Vorlage nutzen. Die richtige Datei ist bei »MdeModulePkg/Application/HelloWorld/HelloWorld.c« zu finden. Listing 2 zeigt diese Datei. Sie wurde erweitert und implementiert nun eine einfache Variante des Spiels Hangman. Der Benutzer muss das Wort »pinguin« erraten und beendet damit die Applikation.
Listing 2
Hello World
01 #include <Uefi.h>
02 #include <Library/PcdLib.h>
03 #include <Library/UefiLib.h>
04 #include <Library/UefiApplicationEntryPoint.h>
05
06 EFI_STATUS
07 EFIAPI
08 UefiMain (
09 IN EFI_HANDLEImageHandle,
10 IN EFI_SYSTEM_TABLE *SystemTable
11 )
12 {
13 UINTN Index;
14 EFI_INPUT_KEY Key;
15 CHAR16 *result = L"pinguin";
16 CHAR16 *state = L"_______";
17 UINTN Attempt = 0;
18
19 do {
20 Attempt++;
21 SystemTable->ConOut->ClearScreen(SystemTable->ConOut);
22
23 Print(L"Welcome to Hangman!\n");
24 Print(L"Attempt: %d\n\n\n", Attempt);
25
26 // print found characters
27 for(UINTN i=0; i<StrLen(state); i++) {
28 Print(L"%c ", state[i]);
29 }
30
31 // read characters from keyboard
32 SystemTable->BootServices->WaitForEvent(1, &SystemTable->ConIn->WaitForKey, &Index);
33 SystemTable->ConIn->ReadKeyStroke(SystemTable->ConIn, &Key);
34
35 // check if pressed key is in result
36 for(UINTN i=0; i<StrLen(result); i++) {
37 if (Key.UnicodeChar == result[i]) {
38 state[i] = result[i];
39 }
40 }
41 } while(StrCmp(result, state) != 0); // repeat until all characters are found
42
43 // print final result
44 SystemTable->ConOut->SetCursorPosition(SystemTable->ConOut, 0 , 4);
45 for(UINTN i=0; i<StrLen(state); i++) {
46 Print(L"%c ", state[i]);
47 }
48 // wait for key
49 Print(L"\n\nCongratulations!\nPress any key to continue...\n");
50 SystemTable->BootServices->WaitForEvent (1, &SystemTable->ConIn->WaitForKey,
51 &Index);
52
53 return EFI_SUCCESS;
54 }
Einstiegspunkt der Applikation ist die Funktion »UefiMain« (Zeile 8). Sie besitzt zwei Übergabe-Argumente. Das »ImageHandle« stellt ein Handle auf den eigenen Prozess dar und ist für die Hello-World-Applikation nicht weiter interessant. Das zweite Argument »SystemTable« ist dagegen eine zentrale Datenstruktur der UEFI-Umgebung. Die »SystemTable« stellt der Applikation nun unter anderem auch den Zugriff auf Protokolle zur Verfügung, die vorher in der DXE-Phase registriert wurden.
In Zeile 21 nutzt das Programm mittels »SystemTable« das Simple-Text-Output-Protokoll. Es firmiert unter dem Namen »ConOut«. Das Protokoll besitzt eine Funktion mit dem Namen »ClearScreeen«. Wie der Name bereits vermuten lässt, säubert dieser Aufruf die Ausgabe-Konsole. Es folgen einige Ausgaben, die die Print-Funktion realisiert. Unter der Haube verwendet die Print-Funktion ebenfalls das Simple-Text-Output-Protokoll. Zeile 32 nutzt den Service »WaitForEvent«. Mit seiner Hilfe wartet das Programm auf das Eintreten von bestimmten Ereignissen, in diesem Fall auf einen Tastendruck (»WaitForKey«). Nach dem Eintreten des Events liefert die Funktion »ReadKeyStroke« die gedrückte Taste.
Die folgende For-Schleife überprüft, ob das Zeichen zu einem der gesuchten Zeichen passt. Der gesamte Vorgang wird durch die Do-While-Schleife so oft wiederholt, bis der Benutzer alle Buchstaben richtig erraten hat. Danach gibt das Programm das gesuchte Wort vollständig aus und wartet dann noch auf einen abschließenden Tastendruck, bevor es sich selbst beendet.
Damit das Hangman-Programm in den nächsten Build einbezogen wird, muss der Entwickler das Ovmf-Paket erweitern. In der Datei »~/src/vUDK2017/OvmfPkg/OvmfPkgX64.dsc« fügt er noch den Abschnitt »[Components]« und einen Verweis auf die Hello-World-Applikation ein:
[Components] MdeModulePkg/Application/HelloWorld/HelloWorld.inf
Die Datei »HelloWorld.inf« beschreibt die Applikation und weist das EDK an, automatisch Makefiles zu generieren. Im Basisverzeichnis des EDK startet der Entwickler den Übersetzungsvorgang für die Hello-World-Applikation:
source edksetup.sh build
Der Build speichert in dem Verzeichnis »~/src/Build/OvmfX64/DEBUG_GCC5/X64« das erzeugte UEFI-Binary »HelloWorld.efi«. Um die Applikation zu testen, kopiert der Entwickler sie in das »efibin«-Verzeichnis und startet Qemu neu:
cd ~/efibin cp ~/src/Build/OvmfX64/DEBUG_GCC5/X64/HelloWorld.efi .
Beim Start erweitert der Entwickler den Befehl zum Starten des Qemu-Systems um den Parameter »hda«. Dieser Parameter bindet das »efibin«-Verzeichnis als FAT formatierte Festplatte in die virtuelle Maschine ein. Der vollständige Befehl:
Qemu-system-x86_64 -drive if=pflash,format=raw,file=OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd -hda fat:~/efibin
UEFI unterstützt das FAT-Dateisystem direkt und hat somit Zugriff auf die Hello-World-Applikation. Nach dem Start der UEFI-Shell gibt der Entwickler »HelloWorld« ein und startet so das Programm (Abbildung 3).
Abbildung 3: Das kleine Wort-Ratespiel Hangman unter UEFI-Kontrolle.
Nach Abschluss der Applikationsentwicklung kann der Entwickler die erzeugte Binärdatei in der UEFI-Umgebung des Mainboards ausführen. Dazu kopiert er sie einfach auf die EFI-System-Partition des Computers:
sudo cp ~/efibin/HelloWorld.efi /boot/efi/
Vergleichbar mit der Qemu-Umgebung kann er die Applikation auch in der UEFI-Implementierung des Mainboards manuell über die UEFI-Shell starten. Nach einem Reset des Computers ist dann eine der Funktionstasten zu drücken, um den normalen Startvorgang zu unterbrechen und stattdessen die UEFI-Shell zu starten. Welche Taste gedrückt werden muss, ist abhängig von der UEFI-Implementierung des Mainboards. Sobald sich der Entwickler in der UEFI-Shell befindet, kann er die Applikation einfach durch Eingabe von »HelloWorld« aufrufen.
Alternativ lässt sich auch ein automatischer Start der Applikation einrichten. Dafür ist der UEFI-Bootmanager über die UEFI-Variablen zu konfigurieren. Am komfortabelsten gelingt dies mit dem Programm »efibootmgr«. Das Programm erzeugt neue Bootvariablen im »efivar«-Filesystem und somit einen Eintrag im Bootmanager des UEFI-Systems.
Vor diesem Schritt sollte sich der Admin aber vergewissern, dass eine Recovery-CD bereitliegt, mit der er eine eventuelle Fehlkonfiguration reparieren kann. Um einen neuen Eintrag zu erzeugen, übergibt er dem Efibootmgr das Argument »create«. Ein Label gibt dem Eintrag einen sprechenden Namen, der Parameter »loader« zeigt den Pfad zur UEFI-Applikation:
efibootmgr --create --label "Hangman" --loader HelloWorld.efi
Im Erfolgsfall antwortet das System mit:
BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000,0001 Boot0000* debian Boot0001* Hangman
Aktuell legt die Bootreihenfolge noch fest, dass der Eintrag mit dem Label »debian« gestartet wird. Der Befehl »efibootmgr –bootnext 0001« ändert diese Reihenfolge für den nächsten Bootvorgang auf den Eintrag mit der Nummer 0001. Startet der Anwender den Computer jetzt neu, führt die UEFI-Firmware einmalig die Hello-World-Applikation aus.
Dieses Beispiel zeigt grundsätzlich, wie einfach UEFI-Programme zu entwickeln sind und sich ausführen lassen. Sie sind dabei nicht auf die simple Ein- und Ausgabe von Text beschränkt. Auch die Entwicklung von grafischen Benutzeroberflächen, die Verwendung von TCP/IP oder der Zugriff auf USB-Datenträger sind damit möglich. In diesem Umfeld lassen sich auch komplexe Applikationen unabhängig von einem bestimmten Betriebssystem ausführen.
