Ich hab mich schon seit einer Weile für UEFI interessiert und früher durch Macs, seit anderhalb Jahren durch meinen neuen Laptop und in den letzten Wochen und Monaten nun auch bei den ersten neuen Servern die Gelegenheit gehabt, mich auch damit zu beschäftigen. (Auch im Freundeskreis tauchten schon diverse Geräte mit UEFI auf — oft gefolgt von den ersten Hilferufen.) Nun steht ein Urlaub an, das ist die perfekte Gelegenheit das gesammelte gefährliche Halbwissen und mühsam erkämpfte Wissen vorher mal in die Schriftform zu dumpen:

(Kleine Bitte vorweg: Wer mag, möge bitte versuchen mitzuzählen, wie oft sie/er beim Lesen die Hände vor den Kopf schlagt oder ähnliches tut. Über entsprechende Kommentare freue ich mich.)

UEFI

UEFI steht für Unified Extensible Firmware Interface und ist Katalog von vereinheitlichten Schnittstellen über die ein Betriebssystem auf die Firmware und die einzelnen Baugruppen eines Rechners zugreifen kann. Es ist als Ablösung für das arg in die Jahre gekommene BIOS gedacht und nachdem es lange Zeit nur bei Apple, einigen Desktop- und Laptop-Modellreihen von Dell und HP, sowie einem kleinen Teil des Servermarktes anzutreffen war, setzt es sich jetzt allmählich durch. (Was im wesentlichen daran liegen dürfte, dass Intel ab den SandyBridge-Prozessoren und -Chipsätzen anscheinend UEFI voraussetzt und Hardware-Hersteller damit gezwungen sind sich endlich vom BIOS zu trennen. Außerdem macht seit kurzem das Windows-8-Logo-Programm das ebenfalls nach UEFI verlangt den Herstellern Dampf.)

UEFI ist dabei nicht eine bestimmte Firmware, es ist nichtmal ein Synonym für Firmware. Ähnlich wie beim BIOS auch gibt es bei UEFI unterschiedliche Implementationen und das Siegel UEFI sagt im Grunde nicht viel über die Firmware aus, außer dass sie bestimmte Funktionen und APIs bereitstellt. Das ist so ähnlich wie beim Begriff Unix: es gibt (heutzutage) nicht das Unix, sondern es gibt sehr viele sehr unterschiedliche Betriebssysteme die unter anderem alle Funktionen und APIs bereitstellen die der Unix-Standard verlangt.

Exkurs: Was war an BIOS zuletzt so schlimm?

BIOS geht auf die frühesten Anfänge der PC-Ära zurück. So lange es „IBM-kompatible PCs“ gab, gab es BIOS (streng genommen gab es BIOS sogar schon vor den IBM-kompatiblen PCs). Aus Kompatibilitätsgründen haben sich mit der Zeit eine Reihe von alten Zöpfen angesammelt, die mehr und mehr zum Hindernis wurden. So läuft BIOS z.B. immer noch im 16-Bit-Modus der x86er CPUs — ist damit einer der Gründe, warum selbst Prozessoren der x86_64-Architektur so einen Museums-Modus noch mitbringen — und zunehmend schwieriger zu warten, nicht zuletzt weil allmählich die Programmierer die 16 Bit Architekturen noch gut kennen alle in Rente gehen. In diesem Modus kann nicht sonderlich viel Speicher adressiert werden, so dass bereits seit vielen Jahren Klimmzüge notwendig sind, um in PCs überhaupt signifikante Mengen Arbeitsspeicher und moderne Festplatten zu verbauen. Wer sich schon mal gefragt hat, warum manche Festplatten eine per Jumper zu setzende Einstellung haben, mit der ihre Kompatibilität auf 32 GB begrenzt wird… ältere BIOS-Versionen können nichts größeres adressieren. Und auch heute gilt noch: Boot-Partitionen gehören an den Anfang einer Festplatte, denn sonst kann der Bootloader-Code aus dem MBR diese nicht adressieren und folglich nicht Booten. Und bei Festplattengrößen jenseits der 2 TB kam das BIOS bzw. das eng damit verbundene MBR Partitionstabellenschema endgültig an seine Grenzen.

BIOS-Einstellungen können nur im BIOS gesetzt werden, es gibt keine einheitliche Schnittstelle, über die dies vom Betriebssystem aus erledigt werden kann. Das ist ärgerlich, denn es verhindert z.B., dass ein von einem Installationsmedium gebootetes Live-System nach erfolgreicher Installation eines neuen Betriebssystems zuverlässig dafür sorgen kann, dass dieses als nächstes gebootet wird. Erfahrene User mag das nicht mehr schrecken, aber ich trage immer noch einen kleinen Rest Hoffnung in mir, dass ich nicht bis an ihr Lebensende meinen Eltern und Großeltern bei all ihren PC-Problemen helfen muss. Da hilft es nur leider wenig wenn die Betriebssystem-Installationen einfacher werden, wenn die Benutzerfreundlichkeit des BIOS auf dem Stand von 1983 stehen bleibt. Meine Mutter kennt PCs ausschließlich mit Maus, dass man im BIOS die Maus nicht benutzen kann verwirrt sie. Kinder die heute aufwachsen werden vermutlich in einigen Jahren noch verwirrter sein, weil das BIOS kein Touch unterstützt.

Ärgerlicherweise gibt es die meisten BIOS-Versionen nur in Englisch, was sie gerade für unerfahrende User die Englisch nicht als Muttersprache erworben haben sehr unzugänglich macht — obendrein wenn diese in Teilen der Welt leben in denen Englisch noch eine viel fremdere Sprache ist als in Europa und Nordamerika. Auch Begrifflichkeiten sind vollkommen uneinheitlich und verwirrend. Ein CPU-Feature das bei Intel einen Namen und bei AMD einen anderen hat (etwa: Virtualisierungssupport) ist ja schon schlimm genug, aber natürlich muss es auch in jedem BIOS andere, verwirrende Namen bekommen und die entsprechende Einstellung muss natürlich in einem anderen Untermenü eines Untermenüs versteckt werden.

BIOS ist im Grunde nicht erweiterbar, bzw. nur auf Umwegen. Es ist ein ziemliches Gefrickel Option-ROMs wie sie viele RAID-Controller und Netzwerkkarten heute häufig mitbringen zu programmieren. Diese Option-ROMs müssen dann ein eigenes User Interface haben, denn sie können nicht in das des BIOS eingeklinkt werden. Folglich müssen die User sich noch eine Tastenkombination merken, um in das User Interface solcher Karten zu kommen.

Wie lange es gedauert hat, bis auf brandneuen PCs zuverlässig auch mit USB-Tastaturen das BIOS angesprochen werden konnte, will ich hier gar nicht weiter ausführen, sonst rege ich mir nur wieder auf.

Und schließlich ist da noch die Idiotie zu erwähnen, daß es in 30 Jahren PC-Architektur nie auch nur im Ansatz gelungen ist mal die Tasten zu standardisieren, die man beim Booten drücken muß um ins BIOS, die Boot Selection, das UI vom Option-ROM eines RAID-Controllers oder einer Netzwerkkarte zu kommen. Moderne PCs zeigen die nötigen Hinweise auf die Tastenkombinationen oft so kurz an, dass selbst schnelle Leser es nicht lesen können. Wie man z.B. an den zahllosen Admins erkennt, die es schon gar nicht mehr versuchen und einfach nur noch genervt eine mehr oder weniger rhythmische Folge von Esc, F1, F2, F4 und Del in die Tasten hämmern, immer wieder und wieder, weil sie ja auch nicht wissen in welcher halben Sekunde das BIOS diese Eingabe erwartet. (Wobei das natürlich alles noch nichts gegen die Firmware-Reboot-Prozedur vieler moderner Autos ist.)

Alles neu macht UEFI

Mit UEFI sollen all diese Absurditäten ein Ende haben (natürlich kommen neue hinzu, dazu später mehr). Bei UEFI ist es endlich möglich dem User ein User Interface zu präsentieren, in dem auch die Maus funktioniert (man munkelt sogar, es könnte irgendwann mal Touch-Support geben) und das nicht mehr aus Klötzchengraphiken besteht und höhere Auflösungen als 640×480 Pixel unterstützt. Die UEFI Oberflächen unterstützten häufig schon viele verschiedene Sprachen, mit UEFI wird aber sogar Support für nicht-lateinische Schriften, rechts-nach-links-läufige Schriftsysteme und theoretisch sogar für andere Ausgabegeräte wie Braille-Zeilen realistischer, was bei BIOS nur selten gemacht wurde. Auch kann das Betriebssystem auf die Bootreihenfolge Einfluss nehmen und es wird leichter, UEFI-Firmwareupdates einzuspielen.

UEFI bietet sogar einen eigenen, standardisierten Netzwerkstack, bei dem zu hoffen steht, dass das Arbeiten in PXE-Umgebungen endlich einfacher und einheitlicher wird. (Wobei abzuwarten ist, ob das am Ende auch funktioniert, bisher wurden offenbar fast alle UEFI-Firmwares ohne Netzwerkstack ausgeliefert.) Im Zusammenhang mit diesem Netzwerkstack wurde auch schon erwähnt, dass es für UEFI wohl Fernwartungsschnittstellen geben soll (wer hier jetzt das gleiche denkt wie ich: auch dazu später mehr).

Für Kommandozeilen-Liebhaber kommt UEFI häufig mit einer Shell daher (wenn nicht, lässt sie sich nachinstallieren), die interessante Möglichkeiten eröffnet und das Debugging erleichtern dürfte.

Es wurde auch schon viel darüber geschrieben, dass UEFI prinzipiell die Möglichkeit bietet plattformunabhängige Treiber für Hardwarekomponenten zu unterstützen. Die Idee ist wohl, dass eine Hardware beim Bootvorgang ihren Treiber in UEFI integriert und das Betriebssystem diesen Treiber später nutzen kann. Hier heißt es bisher erstmal abwarten, denn gesehen haben ich so ein Setup noch nicht und ich bin da anscheinend nicht der einzige.

Vor allem aber kommt UEFI mit vollem Support für ein neues Partitionierungsschema namens GPT, welches das alte, ebenfalls in die Jahre gekommene MBR-Schema ablösen wird. Zu GPT und ihrer Handhabung schreibe ich in Kürze nochmal gesondert etwas. Ich kann aber schonmal sagen, dass ich GPT wesentlich enthusiastischer entgegen sehe als UEFI (bis hin zu aufgeregter Schnappatmung, ich geb’s zu). GPT ist in allen Bereichen eine enorme Verbesserung gegenüber MBR und ich habe bisher noch keine Nachteile daran finden können, die in GPT selbst begründet lägen.

Wenn der MBR in Zukunft weg fällt, stellt sich natürlich die Frage, wie unter UEFI dann die Betriebssysteme booten sollen, denn der MBR enthält ja neben der Partitionstabelle vor allem den Chainloading-Code eines Bootloaders. Das ist was UEFI angeht meiner Meinung nach eines der wichtigsten Themen und ich gehe im weiteren vor allem darauf ein. Aber erstmal zu den Problemen die UEFI allgemein hat:

Die Dunkle Seite der Macht

Es klang bereits an einigen Stellen an: mit den vielen Neuerungen tun sich bei UEFI auch neue Probleme auf. Eines der größten Probleme für den Einstieg ist im Moment, dass UEFI-Firmware nicht gleich UEFI-Firmware ist. Ich habe bisher bei keinem einzigen Computer-Hersteller jemals eine Liste der Features ihrer UEFI-Firmware gesehen. Wenn ich auf Eigenschaften wie den Netzwerkstack angewiesen bin, muss ich bisher erstmal die Katze im Sack kaufen. Das wird ein bisschen dadurch aufgelöst, dass bestimmte Versionen des UEFI-Standards bestimmte Funktionen verlangen, so dass von einer Information wie „UEFI 2.1“ auf den Funktionsumfang geschlossen werden kann. Hier sehe ich allerdings das potentielle Problem, dass viele User Firmware-Version und Version des UEFI-Standards durcheinander bringen werden. Es ist nicht gut, User zu verwirren.

Auch bleibt abzuwarten wie gut und wie lange einmal ausgelieferte UEFI-Firmwares vom Hersteller supported werden. Dabei ist nicht nur interessant, ob Upgrades auf neuere UEFI-Standards (kostenfrei?) angeboten werden, sondern schon die Frage inwiefern Bugfixes und Sicherheitsupdates verfügbar gemacht werden ist spannend. BIOS setzt in diesem Bereich ein wirklich schlimmes Negativbeispiel: Wer hier Fehler oder gar Sicherheitslücken findet (und das wird auch bei UEFI garantiert passieren), wurde oft vom Computerhändler auf den Mainboard-Hersteller verwiesen, dieser verwies auf die Firma welche die Firmware für ihn geschrieben hat und jene sagte dann vielleicht „OK, in unserer Firmware fixen wir das, aber wir können ihnen nicht sagen, ob ihr Mainboard-Hersteller für dieses Mainboard einen Patch rausbringt“. Bleibt zu hoffen, dass das bei UEFI anders laufen wird. Bisher sehe ich leider noch keinen Anlass zum Optimismus.

Beim Thema Fernwartungs-Schnittstelle wird sicherlich nicht nur mir ein kalter Schauer über den Rücken gelaufen sein. Das eröffnet sicherlich interessante Möglichkeiten, aber es eröffnet auch sehr gruselige. Im Hinblick darauf, dass zumindest die deutschen Bedarfsträger sich beim Trojanisieren unserer Computer bisher ziemlich tölpelhaft anstellen, gerate ich hier noch nicht in Panik, aber ich bin beunruhigt. Bedarfsträger einer ganz anderen Art haben auch schon angeklopft und denken laut darüber nach, wie sie UEFI am sinnvollsten mit Trusted Platform Modulen und DRM verheiraten können um die Freiheit der User massiv einzuschränken. Als wenn die PC-Welt noch ein gescheitertes DRM-Konzept bräuchte, säumen ja noch nicht genug rauchende Ruinen den Weg.

Zum Thema Sicherheit ist dann natürlich noch zu erwähnen, dass eine vereinheitlichte Firmwareschnittstelle, die obendrein noch leicht erweiterbar ist und möglicherweise eine Fernwartungsschnittstelle hat selbstverständlich dafür sorgt, dass nicht nur das Auskommen von Viren- und Antiviren-Programmierern für die nächsten Jahre sicher sein dürfte, sondern höchstwahrscheinlich auch deren Rente.

Zu den plattformunabhängigen Treibern wurde wie bereits oben erwähnt schon viel geschrieben — etwa die Hälfte davon offenbar darüber warum das doch nicht oder nur eingeschränkt funktionieren wird. Da ich von hardware-naher Programmierung ohnehin fast nichts verstehe, warte ich hier einfach mal ab, ob ich da in den nächsten Jahren Demonstrationen von sehe oder nicht. Es wäre sicherlich ein praktisches Feature, aber ich gerate hier nicht in aufgeregte Schnappatmung. Als Linux-User sind meine Erfahrungen mit Treibern die vom Hardware-Hersteller stammen nicht so prickelnd gewesen, in der Regel sind Treiber aus dem Linux-Umfeld oder besser noch Treiber aus dem Linux-Kernel (an denen der Hersteller mitgearbeitet hat oder auch nicht) doch die besten.

Die Möglichkeit in Zukunft UEFI durch eine freie Alternative wie Coreboot zu ersetzen wird es nicht geben. Coreboot ist zwar nur ein kleines Projekt, aber wer mal eine Demonstration von denen gesehen hat, wird sich fragen warum man sich den Aufwand mit UEFI überhaupt gemacht hat, wenn man statt dessen eine freie Software wie Coreboot hätte nehmen und weiterentwickeln können. (Vielleicht liegt es daran, dass Coreboot auf Linux aufbaut und damit die GPL ins Boot holt. Eine BSD-Lizenz wäre hier sicherlich erheblich attraktiver.)

Und die Tastaturkürzel die das UEFI User Interface aufrufen wurden natürlich nicht vereinheitlicht oder die Hersteller halten sich nicht dran. 🙁

Schließlich und endlich bleibt zu bemängeln, dass sich niemand wirklich Gedanken über die Übergangsphase zwischen BIOS und UEFI gemacht zu haben scheint und insbesondere bei den Softwareherstellern der Support für UEFI auch reichlich spät eintrifft. Was mich zum nächsten und erstmal wichtigsten Punkt bringt:

Der UEFI-Boot-Vorgang

Die wichtigste Änderung bei UEFI für User und Administratoren betrifft den Bootvorgang. Kurz zur Erinnerung, so bootet BIOS (vereinfacht):

Mainboard bekommt Strom, Firmware führt Power-on-self-test (POST) aus und piept bei Erfolg.

Prozessor erhält Strom und lädt die Start-Instruktionen vom Beginn des Festspeichers (das ist ein spezieller Speicherbereich) und lädt damit das BIOS

BIOS lädt aus seinem CMOS Speicher seine Konfiguration, sofern eine vorhanden ist.

BIOS führt einen simplen RAM-Check aus, dieser kann per Konfiguration abgebogen werden.

BIOS klappert unter Berücksichtigung seiner Konfiguration alle Adressen auf seinen Bussen ab um vorhandene Hardware zu erkennen und konfiguriert sie.

Zuletzt werden Speichergeräte angesprochen. BIOS versucht festzustellen von welchen überhaupt gebootet werden kann und von welchem gebootet werden soll.

BIOS liest die ersten 512 Byte von dem Speichergerät von dem gebootet werden soll in dem RAM und führt den darin enthaltenen Code aus und gibt damit die Kontrolle über den Rechner an diesen weiter.

Bei UEFI kommen nun vor allem für die letzten Schritte erheblich mehr Funktionen hinzu, „hinzu“ deshalb, weil UEFI durchaus auch in der Lage ist einen BIOS-Bootvorgang zu emulieren und dem Betriebssystem vorzumachen, es wäre von BIOS gebootet worden. Einem so gebooteten Betriebssystem stehen allerdings leider alle erweiterten Funktionen von UEFI nicht zur Verfügung.

Wenn aber ein UEFI-Boot ausgeführt wird, schaut sich UEFI die Speichergeräte etwas genauer an. Es sucht nicht einfach nur das vorkonfigurierte Gerät und liest mehr oder weniger blind die Instruktionen aus dessen ersten 512 Bytes, sondern es schaut ob es eine GUID Partitionstabelle (GPT) vorfindet, analysiert diese und sucht dort nach eventuell vorhandenen UEFI-Boot-Partitionen (die sich überall auf dem Speichergerät befinden können). Dann ist UEFI in der Lage FAT32-Dateisysteme (und ISO-Joliet) zu lesen. Wenn es also auf einem Speichergerät in einer GPT eine als bootfähig markierte Partition vorfindet in der so ein Dateisystem liegt, sucht es in diesem Dateisystem an einem bestimmten Ort nach geeigneten Dateien. Diese Pfade konstruieren sich wie folgt: „\EFI\BOOT\BOOT[$ARCH].EFI“, also z.B. „\EFI\BOOT\BOOTx64.EFI“. Wenn eine oder meherere Dateien (mehrere natürlich nur in verschiedenen Dateisystemen) vorhanden sind und es sich dabei um UEFI-Binaries handelt, kann es dem User diese Bootoption präsentieren und sie auf Verlangen laden. (Problem daran ist nur, dass UEFI nur bestimmte Pfade und Namen prüft, für alle anderen UEFI-Binaries die anderswo in der UEFI-Boot-Partition liegen oder anders heißen, muss man selbst eine Bootoption konfigurieren.)

Was können solche UEFI-Binaries sein? Einerseits natürlich Bootloader, das war ja klar. Aber es können auch Diagnose-Tools sein (zum Beispiel für Festplatten oder RAM), es kann ein Shell-Interpreter sein, der eine UEFI-Shell ausführt, theoretisch kann es alles mögliche sein, was man für UEFI kompilieren kann. Und das beste daran: man kann solche Tools auch wieder verlassen und kommt dann wieder in die UEFI-Umgebung zurück und zwar ohne Neustart. Angesichts dessen wie lange RAID-Controller manchmal beim Booten brauchen, ist das eine echte Erleichterung. (So wie ich diese Sache verstehe, können so auch Tools geladen werden, die auch nach dem Boot eines Betriebssystems aktiv bleiben, so genannte Runtime Services, darunter dürften dann wohl auch die ominösen plattformunabhängigen Treiber fallen. Das könnte aber auch für Debugger interessant sein. Und — natürlich — für Viren und Antiviren.) Prinzipiell können hier auch Dateisystemtreiber nachgeladen werden. Es ist also durchaus denkbar, dass Betriebssysteme wie Linux in Zukunft auf Bootloader verzichten und statt dessem UEFI um ext-, btrfs-, xfs-, und reiserfs-Treiber ergänzen (oder was sonst noch weit verbreitet ist) und dann UEFI direkt den Kernel booten lassen. Andersrum kann man den Kernel natürlich auch einfach in die FAT32-Partition packen, die UEFI ohnehin schon lesen kann.

Noch spannender wird diese Sache im Bezug auf Netzwerkumgebungen. Es ist absehbar, dass für UEFI NFS-, iSCSI- und FibreChannel-Binaries geschrieben werden, bzw. dies geschieht bereits. Aber auch für exotischere Systeme eröffnen sich hier neue Möglichkeiten. Grundsätzlich läßt sich sagen, daß die Einführung von neuen Lösungen in diesem Bereich in Zukunft einfacher werden dürfte, weil es eben nicht mehr erforderlich sein wird einen OptionROM auszuliefern (für den auch erstmal kompatible Sockel vorhanden sein müssen), sondern es mit einem Binary für UEFI getan sein könnte. Ich wäre ja mal an einem PXE-Boot interessiert der über IPsec läuft…

Leider konnte ich den Netzwerkboot unter UEFI noch nicht ausprobieren, mein anderthalb Jahre alter Dell Latitude Laptop hat zwar UEFI, allerdings konnte ich bisher keine Dokumentation darüber finden, ob hier ein UEFI-Netzwerkstack dabei ist oder nicht und wie man den wenn dann anspricht (ein PXE OptionROM ist natürlich vorhanden). Im Rechenzentrum haben wir zwar jetzt die ersten Server mit UEFI, in deren Einstellungsdialogen (die anders als bei Dell enttäuschend BIOS-ähnlich aussehen) sich auch die Option findet den Netzwerkstack zu (de)aktivieren, aber auch hier fehlt es bisher an Dokumentation. Die Manpage von efibootmgr (ein Programm um unter Linux UEFI-Booteinträge zu konfigurieren) stimmt mich nicht optimistisch:

CREATING NETWORK BOOT ENTRIES

A system administrator wants to create a boot option to network boot (PXE). Unfortunately, this requires knowing a little more information about your system than can be easily found by efibootmgr, so you've got to pass additional information - the ACPI HID and UID values.

These can generally be found by using the EFI Boot Manager (in the EFI environment) to create a network boot entry, then using efibootmgr to

print it verbosely. Here's one example:

Boot003*Acpi(PNP0A03,0)/PCI(5|0)/Mac(00D0B7F9F510)\ACPI(a0341d0,0)PCI(0,5)MAC(00d0b7f9f510,0)

In this case, the ACPI HID is "0A0341d0" and the UID is "0". For the zx2000 gigE, the HID is "222F" and the UID is "500". For the rx2000 gigE, the HID is "0002" and the UID is "100". You create the boot entry with: efibootmgr -c -i eth0 -H 222F -U 500 -L netboot



Alles klar, oder?

Ich freue mich schon darauf, Ungetümer wie „Boot003*Acpi(PNP0A03,0)/PCI(5|0)/Mac(00D0B7F9F510)\ACPI(a0341d0,0)PCI(0,5)MAC(00d0b7f9f510,0)“ von Hand in der UEFI-Shell eingeben zu müssen, wenn mal was debuggt werden muss. So kompliziert ist ja noch nichtmal mein Root-Passwort. Und selbstverständlich ist mir die ACPI HID meiner Netzwerkkarte absolut geläufig, die lerne ich noch vor meiner IP-Adresse! — Hier muss eindeutig noch erheblich nachgebessert werden, so wie das bisher gelöst ist, ist es selbst für routinierte Admins zu unhandlich.

Soviel erstmal allgemein zum Bootvorgang. Für User und Administratoren wird erstmal relevant sein, dass UEFI alle angeschlossenen Speichergeräte nach Bootoptionen durchsucht und diese in einer Bootauswahl präsentiert — soweit zumindest die Theorie. Die Praxis sieht leider anders aus:

Henne oder Ei?

Wer heute ein Betriebssystem installieren will, macht das mit CDs, DVDs, USB-Sticks oder einer PXE-Umgebung. (Oder verwendet etwa noch jemand Schlappscheiben?) Die CDs, DVDs und USB-Sticks die hierfür normalerweise verwendet werden sind für BIOS ausgelegt. UEFI kann diese allerdings über seine Legacy-Boot-Optionen booten. Soweit so gut. Erstmal.

Das Problem hieran ist: ein so gebootetes Betriebssystem kann nicht auf die neuen Funktionen von UEFI zugreifen. Es hat daher absolut keine Möglichkeit einen UEFI-Bootloader den es installiert in die UEFI-Konfiguration einzutragen. Schlimmer noch: Es hat nichtmal eine Möglichkeit festzustellen, ob der Computer auf dem es läuft überhaupt mit UEFI ausgestattet ist. Wem jetzt noch nicht das Augenlid zuckt: Bisher scheint kein Betriebssystem-Installer auf gut Glück einfach einen UEFI-Bootloader auf die Festplatte legen zu wollen, in der Hoffnung dass UEFI ihn dort finden und als Bootoption anbieten könnte. Der Grund ist offenbar, dass UEFI eben pro Bootpartition nur eine bestimmte Datei als Bootoption darstellt, nämlich in den meisten Fällen „\EFI\BOOT\BOOTx64.EFI“ — und die meisten Installer wollen genau dort offenbar nichts hinlegen, damit sie nicht eine Datei überschreiben, die dort schon liegen könnte. Na, zuckt es jetzt im Augenlid?

Die einzige Möglichkeit die in so einen Szenario bleibt, ist die vor den Kopf geschlagenen Hände wieder runter zu nehmen, sich ein Tutorial über die UEFI-Shell zu schnappen, diese zu Booten (ggf. muß sie vorher installiert werden) und in dieser Shell einen vorher installierten UEFI-Bootloader des Betriebssystems auszuwählen und zu booten. Wenn die UEFI-Shell sich mehr wie eine richtige Shell und weniger wie DOS anfühlen würde, würde mir das ja noch Spaß machen, aber den meisten Leuten sicherlich nicht. Ist das System einmal unter UEFI gestartet, kann man geeignete Tools verwenden um einen Booteintrag in UEFI anzulegen, damit der nächste Boot dann ohne Shell geht. Zumindest dieser letzte Schritt ist unter Linux mit efibootmgr ziemlich einfach, um nicht zu sagen trivial. Die vorigen Schritte sind es aber nicht.

Halten wir also fest: von einem per Legacy Boot geladenen System (egal ob es ein Installer, ein Live-System mit Installer oder ein fertig installiertes Betriebssystem ist) auf einen UEFI-Boot umzusteigen ist nur etwas für Leute die Spaß am Gerät und Nerven haben. Wer es hin bekommt darf sich freuen. Aber erzählt Euren Freunden gar nicht erst, dass das prinzipiell möglich ist, sonst müsst Ihr ihnen dabei helfen, wenn sie es nicht hinbekommen.

Der einzige für normale User gangbare Weg der zu einem nativen UEFI-Boot des Betriebssystems führt ist der über einen Installer, der schon per UEFI gebootet wird. (Hier gibt es wieder einen Anlass die Hände vor den Kopf zu schlagen: bisher geben viele UEFI-Systeme per default einem Legacy-Boot den Vorzug, auch wenn ein UEFI-Boot möglich wäre!) Ich konnte aktuell keine Linux-Distribution finden, die schon einen bei mir funktionierenden Installer für UEFI ausliefert. Bei Ubuntu, Fedora und OpenSuse scheint die Entwicklung am weitesten voran geschritten zu sein, dort sucht man leider relativ lange nach hilfreichen und guten Anleitungen. Bei ArchLinux sieht es auch schon gut aus, dort findet man auch schnell eine meiner Meinung nach tolle Anleitung.

Wie sieht es in der Praxis aus? — Ich hab versucht geeignete USB-Sticks zu erstellen (ich installiere nur noch vom USB-Stick, drehende Scheiben sind mir zu langsam und ich hasse das schrabbelnde Geräusch in den Laufwerken) und damit zu installieren. Bei Ubuntu liegt mein jüngster Versuch am weitesten zurück, mit 12.04 Precise Pangolin klappte es bei mir im Mai noch nicht (12.10 Quantal Quetzal teste ich voraussichtlich in den nächsten Wochen). Mit Fedora 16 Verne hatte ich kurz nach seinem Release auch kein Glück. OpenSuse mag ich nicht. Bei ArchLinux konnte ich vor zwei Monaten zwar den Installer unter UEFI booten, er hat jedoch keinen funktionsfähigen Bootloader installieren können. (Ich hab dann wieder zur UEFI-Shell gegriffen, dann ging es natürlich.)

Selbst wenn man dem Installer hilft (eigentlich erwarte ich aber, dass alles „out of the box“ funktioniert), gibt es später zum Teil noch Probleme mit dem Handling. Bei Ubuntu 12.04 wird nach Kernel-Updates die grub.cfg in den Ordner /boot/grub/ gelegt. Der Bootloader liegt aber in „/boot/efi/efi/grub/grub.efi“ und erwartet seine Config im selben Ordner unter „/boot/efi/efi/grub/grub.cfg“. Bei ArchLinux und CentOS hatte ich ähnliche Probleme.

Fedora und Ubuntu sind nun Linux-Distributionen die eher für den Desktop-Einsatz gedacht sind und die zumindest ich auf Servern eher nicht haben möchte. ArchLinux ist für Server schon interessanter, da habe ich es aber bisher nicht ausprobiert. In der Firma setzen wir auf unseren Servern bekanntermaßen vorwiegend CentOS ein und da scheint in der aktuellsten Version 6.3 der UEFI Support bisher nicht sehr weit fortgeschritten zu sein. Nun wird das Release von RHEL 6.4 schon erwartet und CentOS 6.4 dürfte zügig folgen. Ich rechne durchaus damit, dass RHEL 6.4 besseren UEFI-Support haben wird, denn gerade im Business-Bereich auf den RHEL ausgerichtet ist breitet sich UEFI durch SandyBridge und das Windows-8-Logoprogramm schnell aus. (Solange UEFI den LegacyBoot aber noch anbietet, ist RedHat hier wie alle anderen Betriebssystemhersteller noch nicht in Zugzwang.)

Gerade was den Einsatz auf der Arbeit angeht, habe ich aber noch ein Problem: Im Rechenzentrum hantieren wir nur ungern mit CD/DVD-Laufwerken und USB-Sticks, da wollen wir lieber mit unserer schönen, mit viel Mühe gepflegten PXE-Umgebung arbeiten. Und da wird es nun wirklich haarig. Ein normaler PXE-Boot per OptionROM ist für UEFI ein LegacyBoot, das bringt mich nicht weiter. Denn auch wenn ich bereit bin auf meinen privaten Rechnern oder auch meinem Arbeitsgeräten von der Firma mit der UEFI-Shell zu hantieren, bei Servern kommt das überhaupt gar nicht in die Tüte. Da muss das Setup zuverlässig, einfach und am besten automatisierbar ablaufen. (Und für User die nicht so drauf sind wie ich finde ich alles andere auch unzumutbar.)

Bei UEFI muß der PXE-Boot also offenbar über den Netzwerkstack von UEFI erfolgen. Die Dokumentation hierzu ist bisher leider noch sehr spärlich gesät und wie bereits erwähnt kommt offenbar auch längst nicht jede UEFI-Firmware mit einem eigenen Netzwerkstack daher. Bei unseren Servern scheint das zwar der Fall zu sein, aber bisher habe ich es dort noch nicht ans Laufen bekommen. Wenn es mir endlich gelingt, werde ich sicherlich wieder etwas dazu schreiben.

Ich fasse mal zusammen:

Viele (nicht alle) UEFI-Systeme booten bevorzugt im Legacy-Modus — wenn die User es nicht anders einstellen — auch wenn ein UEFI-Boot möglich wäre.

Aus einem per Legacy-Boot gestarteten Betriebssystem führt kein einfacher Weg zu einem UEFI-Boot.

Bisher kann zumindest ich nicht von vielen erfolgreichen UEFI-Boots von Betriebssystem-Installern „out of the box“ berichten.

Wie Netzwerk-Boots im UEFI-Modus funktionieren ist mir noch ein völliges Rätsel.

Das sieht mir alles sehr nach einem ernsthaften Henne-Ei-Problem aus. Und da kommt dann noch hinzu, dass die Industrie sich mit UEFI schon seit vielen Jahren ziert. Ich denke ich übertreibe nicht, wenn ich sage dass aus meiner Sicht hier genügend Hennen und Eier rumlaufen und -liegen für eine ganze Geflügelfarm.

Alles in allem muss ich sagen, dass mir das ganz und gar nicht gefällt. Wenn ich mal vergleiche mit der Zeit als ich mir angelesen habe wie PXE funktioniert und mir zum ersten Mal eine PXE-Umgebung gebaut habe, oder als ich zum ersten mal mit den Bootloader Uboot in Berührung kam, dann kommt UEFI dabei ganz schlecht weg. Ich hab wesentlich mehr Zeit darauf verwendet und weiß wesentlich weniger mit Gewissheit. Die Komplexität ist mir für mich selbst schon zu hoch, für normale User finde ich das wirklich unzumutbar.

Und als wenn das reine Booten von UEFI noch nicht kompliziert genug wäre, kommt jetzt auch noch Kryptographie dazu:

Secure Boot: Das Imperium schlägt zurück

Alle Leute die mit Computern Geld verdienen (außer den Viren- und Antiviren-Programmierern) wollen, dass unsere Computer sicherer werden. Es gab in der Vergangenheit schon Viren, die sich in den Bootprozess des Betriebssystems eingeschrieben haben und so dafür gesorgt haben, dass sie noch vor dem Betriebssystem geladen werden und so ein derart hohes Zugriffslevel auf dem Computer haben, dass Antiviren-Programme im Grunde gar keine Chance mehr haben sie zu finden. Wir können davon ausgehen, dass solche Angriffe wenn sie in Form von Viren in freier Wildbahn beobachtet werden, im wesentlich weniger sichtbaren Feld der gezielten Attacken auf ausgewählte Ziele schon viel länger und häufiger stattfinden. Deswegen wird im Rahmen von UEFI an einer Technik gearbeitet, die das Problem entweder lösen oder zumindest verlagern soll: UEFI Secure Boot.

Dabei soll UEFI (der damit implizit vertraut wird, wie berechtigt dieses Vertrauen ist wird sich noch zeigen) bevor sie Bootloader (oder Betriebssysteme direkt) bootet kryptographische Signaturen prüfen, die an der Software angebracht werden. Hierbei gibt es mehrere Probleme:

Im Hinblick darauf, wie lange BIOS sich gehalten hat, muss bei UEFI eine ähnlich lange Lebenszeit befürchtet werden. In 30 Jahren könnten bereits Quantencomputer existieren, wodurch alle Kryptographie die derzeit für Secure Boot vorgesehen ist null und nichtig wäre. Eine Prozedur wie man in so einem Fall zeitnah und den Markt möglichst weit durchdringend neue UEFI-Versionen durchsetzt die dann auf „Post Quantum Computing“-Kryptographie setzt ist noch völlig unklar. Hier wird m.E. etwas wenig voraus geplant.

Für die Signaturen wird mal wieder eine Public Key Infrastructure (PKI) benötigt. Und was bietet sich da besser an als die PKI von SSL, die wir auch bei HTTPS seit so vielen Jahren einsetzen. Wenn wir alle ganz fest die Augen zukneifen und uns die Finger in die Ohren stecken, dann merken wir garantiert nicht, dass diese PKI mittlerweile nur noch zu Hälfte steht und die andere Hälte schon eine rauchende Ruine ist.

Sie wie es aussieht, werden Geräte mit UEFI in jedem Fall mit einer Art vorinstalliertem Master-Key ausgeliefert werden. Sie werden Signaturen, die von diesem Key abgeleitet sind vertrauen. Offenbar wird eine CA wie Thawte diesen Key verwalten. Es steht also zu befürchten, dass Bedarfsträger und andere Malware-Autoren sich über kurz oder lang dort Signaturen besorgen wollen werden — und welches Unternehmen würde da Nein sagen wollen? Hinzu kommt noch, daß es in der Vergangenheit schon häufiger zu Schlampereien bei CAs gekommen ist — auch bei Thawte — durch die Dinge signiert wurden, die niemals hätten signiert werden dürfen. In der Vergangenheit wurde auch schon bei CAs eingebrochen.

Außerdem werden wohl mindestens die meisten PCs (bis auf Server, vielleicht) mit einem vorinstallierten Key von Microsoft ausgeliefert werden, damit sie ein vorinstalliertes Windows booten können oder man auf dem PCs problemlos Windows installieren kann.

Es ist eine Blacklist vorgesehen, über die Signaturen auch widerrufen werden können.

Es soll einen Setup-Mode geben, in dem der User eigene Keys denen er vertraut installieren kann. Ob dieser Modus auch für Enduser verfügbar sein wird, oder nur auf Buisness-PCs und Servern, ist derzeit nicht mit beruhigender Klarheit zu erfahren. Für’s erste sieht es so aus, als wolle zumindest Microsoft den Shitstorm vermeiden, der anstünde wenn PCs auf den Markt kämen, auf denen man nur Windows installieren kann. Aber ob das so bleibt? So ein Monopol kann sehr verlockend sein, besonders bei unseren handzahmen Kartellbehörden.

Von Apple war noch nicht viel zu hören darüber, ob und wie sie Secure Boot einsetzen werden und welche Keys sie vorinstallieren werden.

Es ist noch nicht klar, wie Linux in Zukunft auf PCs installiert werden wird. Es gibt verschiedene Möglichkeiten. Secure Boot abzuschalten wäre die einfachste, aber das würde den Eindruck erwecken, dass Linux zu installieren einen Sicherheitsnachteil bringt. Man könnte Linux direkt von UEFI booten lassen und müsste dann den Linux-Kernel signieren lassen (aufwendig, muß man bei jeder neuen Version wiederholen), oder man müsste den Bootloader signieren lassen (wobei es für Linux meiner Zählung nach mindestens fünf gibt: grub, grub2, lilo, elilo und uboot, auch hier müsste wieder jede neue Version signiert werden). Oder man entwickelt einen extrem simplen Chainloader der signiert wird, selten Updates bekommt und der nur dazu da ist einen Bootloader zu laden (das wird häufiger unter dem Begriff „shim“ diskutiert). Was auch immer man signieren lassen wird: die spannende Frage ist, wo die Signatur herkommt. Man könnte sich zum Beispiel eine Signatur bei Microsoft holen. Viele Linux-User werden sich mit der Hand Microsofts so nah an der Kehle ihres Betriebssystems vermutlich nicht wohl fühlen. Der Key könnte auch von einer CA stammen, die im Idealfall anders als Microsoft kein Eigeninteresse daran haben könnte Linux von bestimmten Geräten fernzuhalten, was aber noch nicht heißt, dass die garantiert immer unparteiisch sein wird, denn eine öffentliche Aufsicht über die Signatur-Verfahren ist nicht vorgesehen. Folglich gibt es wenn es zu Problemen kommen sollte auch erstmal keinen schnellen Klageweg, sondern es muss erstmal vor Gericht dargelegt werden wo das Problem ist und das Gericht muss das auch so sehen.

Microsoft veranstaltet routinemäßig für ihre Betriebssystem-Versionen Logo-Programme. Für Windows 8 sieht es derzeit so aus, als müssten PCs damit sie das Windows 8 Logo erhalten in jedem Fall Secure Boot unterstützen und bei Auslieferung auch aktiviert haben. Einzig bei Servern soll die Option bestehen, dass bei diesen Secure Boot zwar vorhanden, aber nicht aktiv ist. Wie das bei zukünftigen Windows-Versionen aussehen wird ist noch völlig unklar. Es zeichnet sich aber ab, dass Microsoft Secure Boot nutzen möchte, um neue Märkte abzustecken, so sollen nämlich Tablets mit Windows 8 so konfiguriert ausgeliefert werden, dass Secure Boot dort nicht deaktiviert werden kann. Wer solche Anstalten macht erinnert mich zwangsläufig an den berühmten Ausspruch Walter Ulbrichts: „Niemand hat die Absicht eine Mauer zu errichten.“

Nicht nur Software, auch Hardware die Firmware-Komponenten mitbringt (etwa RAID- und Netzwerk-Controller) muss für diese Software Signaturen vorweisen. Unter Umständen werden daher die Keys diverser Hardwarehersteller auf neuen Geräten vorinstalliert sein, was die Angriffsfläche auf die PKI noch weiter vergrößert. Vor allem aber werden Kompatibilitätsprüfungen beim Aufrüsten von Computern komplexer. Genau das, was man als Admin nicht hören will. Beim Aufrüsten oder beim Einbau von Ersatzteilen nicht nur mit BIOS- und Firmware-Versionen zu kämpfen, sondern auch noch mit Signaturen… klar, mach ich gerne, ich genieße es im Rechenzentrum in mieser Luft zwischen lauten Maschinen im Luftzug zu stehen und dabei Kryptographische Fingerprints zu vergleichen.

So ganz traue ich dieser Sache nicht nicht, aber ich mache mir auch keine allzu großen Sorgen. Wie zuletzt bei der Playstation 3 zu sehen war, ist der sicherste Weg für einen Hersteller seine Digital Restrictions so schnell wie möglich gebrochen zu bekommen der, Linux von seinen Geräten auszusperren. Niemand hat sich die Mühe gemacht die Schutzfunktionen der PS3-Firmware zu überwinden, solange Linux auf den Geräten einfach so ausgeführt werden konnte. Kaum wurde diese Funktion (im April 2010) weggenommen, stand schon der erste Jailbreak für die Playstation 3 zur Verfügung (August 2010). Und als Kollateralschaden konnte mit diesem Jailbreak nicht nur wieder Linux installiert werden, sondern kurze Zeit später ist auch der Kopierschutz der Plattform den Weg aller Kopierschutze gegangen.

Mach wir uns nichts vor: Es geht hier auch um Digital Restrictions. Und somit stellt sich hier die Frage was wichtiger ist: die PC Plattform insgesamt ein bisschen sicherer zu machen, oder wirtschaftliche Interessen einzelner Unternehmen durchzusetzen. Wenn mit Secure Boot wirklich nur die Plattform sicherer gemacht werden soll, dann wäre es in jedem Fall klug dafür zu sorgen, dass Linux- und BSD-Distributionen (und alle sonstigen Betriebssysteme) weiterhin problemlos installiert werden können und dafür auch Garantien zu geben. Malware-Entwickler und sogenannte Bedarfsträger werden ohnehin versuchen Secure Boot anzugreifen. Es ist aber nicht nötig die wesentlich größere Linux-Gemeinde hier mit ins Boot zu stoßen (Wortspiel nicht beabsichtigt) und durch ein Aussperren von Linux einen riesigen Anreiz für das Brechen von Secure Boot zu schaffen.

Unabhängig davon muss ich sagen, dass ich meine Computer nicht erst mit einem Jailbreak versorgen müssen möchte, selbst wenn ich zuversichtlich bin, dass dies nötigenfalls möglich wäre. (Aus dem gleichen Grund kaufe ich keinen iPhones mehr.) Auf Servern kommt das im Grunde überhaupt nicht in Frage (hier ist der Markt für Linux aber auch so groß, dass die Gefahr viel geringer ist), aber auch auf PCs oder gar Tablets möchte ich wirklich nicht, dass solche Unsitten da überhaupt erst einreißen.

Fazit

Ich sage es ganz offen: Ich hätte lieber Coreboot mit GPT-Support auf meinen PCs, auch auf den Servern, als UEFI. Aber wenn ich nur die Wahl zwischen BIOS und UEFI bekomme, nehme ich lieber UEFI. Aber nur knapp. Bei der Entwicklung von UEFI wurde m.E. viel zu sehr von der technischen Seite her gedacht und viel zu wenig an die künftigen User.

Hier muß die Schuld aber fair verteilt werden:

Da ist einerseits der technische Standard UEFI, der sicherlich erheblich schlanker und benutzerfreundlicher sein könnte. Ein auf das allernötigste reduzierter BIOS-Nachfolger würde letztlich auch die Angriffsfläche verkleinern. Gerade unter dem Sicherheitsaspekt verstehe ich ohnehin nicht, warum hier nicht zu einer gemeinsamen, quelloffenen Lösung gegriffen wurde. Einwände gegen die GPL kann ich an der Stelle verstehen, aber es spräche sicherlich nichts gegen etwas unter einer BSD-ähnlichen Lizenz. (Erinnert sich noch jemand an die schöne OpenFirmware der alten Suns? Beim bloßen Gedanken daran bekomme ich schon feuchte Augen.) Statt mehrerer, unabhängiger Implementationen könnte man sich auf eine oder zwei gut und öffentlich ge-audit-e Implementationen verlassen und mehr Energie in Updates für diese Software stecken. Wenn der Funktionsumfang überschaubar genug wäre, könnte man den Code vielleicht sogar durchbeweisen (falls das was bringt).

Auf der anderen Seite stehen Hardware- und Betriebssystemhersteller (von denen einige an UEFI mitgewirkt haben), die sich wirklich besser um die Benutzerfreundlichkeit hätten bemühen können. Wie üblich schneidet hier Apple besser ab als alle anderen, aber das will nicht viel heißen. Eine Schildkröte ist auch schneller als eine Schnecke, das macht sie noch lange nicht zu einem schnellen Tier. Vor allem aber wäre eine koordinierte Einführung von UEFI über einen kurzen Zeitraum von wenigen Jahren sicherlich sinnvoller gewesen als das nun seit bald 10 Jahren andauernde Rumgeeiere. (Wieder etwas, das Apple gut vorgemacht hat, dort erfolgte die Umstellung binnen eines einzigen Jahres.) Vor allem aber fehlt es UEFI an einem: einer vernünftigen, durchdachten und einfachen Migrationsstrategie die Henne-Ei-Probleme vermeidet.

Schließlich bleibt die politische Dimension. Im Grunde hat sich das Thema UEFI für mich schon fast erledigt gehabt, als überhaupt die Diskussion aufkam, ob man damit Betriebssysteme wie Linux von einer Plattform aussperren könnte. Warum wurde das nicht von vornherein abgebogen? Warum gibt es keine gemeinsame Organisation aller an UEFI interessierten, die einfach allen Betriebssystemen die glaubhaft machen können, dass sie bemüht sind keine Malware zu sein, Signaturen gibt? Es gibt bis heute keine einzige solche Digital Restriction Maßnahme, die nicht überwunden wurde. Aus der Alchemie wurde wenigstens irgendwann die Lehre gezogen, dass sich Gold eben nicht machen läßt. Wie lange wird es in der Computerindustrie noch dauern, bis die Lehre gezogen wird, dass Digital Restrictions einfach nicht funktionieren?

Alles in allem: UEFI kommt, soviel steht wohl fest. Es bringt ein paar schöne Neuerungen und leider auch einen Haufen neuer Probleme. Vielleicht wird’s dann ja was mit dem UEFI-Nachfolger. Wir sprechen uns in 30 Jahren.