UEFI

UEFI

Mit UEFI (Unified Extensible Firmware Interface, auf deutsch etwa "Vereinheitlichte erweiterbare Firmware-Schnittstelle") setzt sich derzeit auf x86_64 Architektur und nicht zuletzt forciert durch die Marktmacht von Microsoft ein Nachfolger für das technologisch veralteten BIOS durch. UEFI hat die Aufgabe neben der Initialisierung der Hardware das Starten eines Betriebssytems einzuleiten. Während das BIOS nur das minimal Notwendigste zur Verfügung stellen konnte, handelt es sich beim UEFI im Grunde um ein Embedded-System also um ein pre-boot Operating System. Dieses macht vieles sowohl für Hard- und Softwarehersteller als auch für den Benutzer einfacher, aber auch vieles möglich, dass bisher für einen PC-Benutzer nicht im Traum vorstellbar war und eventuell auch nicht wirklich immer seinen Vorstellungen und Interessen entspricht.

Vergleich UEFI und BIOS

Sowohl beim BIOS als auch beim UEFI-BIOS handelt es sich um die Firmware des Systemboards, das auf einem nichtflüchtigen Speicher auf jedem Systemboard abgelegt ist. Hauptaufgabe ist das Initialisieren der Hardware beim Einschalten und Reseten, sowie das Starten des Betriebssystems einzuleiten und die dafür erforderlichen Schnittstellen zur Hardware zur Verfügung zu stellen. Der für den User sichtbare Teil ist ein Setuptool, mit dem vom User Einstellungen vorgenommen werden können. Beide enthalten auch Schnittstellen, die vom laufenden Betriebssystem aus erreichbar sind und dem Betriebssystem Zugriff auf Einstellungen und Funktionen der Hardware ermöglichen.

Bei einem sehr grob vereinfachtem Funktionsablauf beim Starten des Rechners könnte man auf die Idee kommen, hier ist nur ein Modul Namens UEFI zwischen BIOS und dem Betriebssystem eingeschoben worden. Dieser Schein trügt, wenn man sich die Unterschiede genauer anschaut.

Unterschied im Design

Bei einem tieferen Blick in die Struktur des BIOS würde man eine Art Softwareklotz sehen, bestehend aus tausenden bunten Einzelteilen, die kunterbunt ineinander verschwimmen, einen zusammengeschweißten, in sich geschlossener Fleckenteppich. Beim UEFI-BIOS hingegen würde sich eine sehr detaillierte und klare, feingliedrige Struktur aus klar umrissenen Bausteinen aufzeigen, mit Möglichkeiten einzelne Bausteine zu erweitern, ohne das Gesamterscheinungsbild zu stören. Unter Beteiligung von mehr als 10 namhaften Technologiekonzernen wurde für den UEFI-BIOS ein eigener Industriestandard entwickelt, bestehend aus Dutzenden von Spezifikationen, welche jede einzelne Funktion und Schnittstelle in der Software klar definiert. Diese Spezifikationen sowie auch Opensource Referenzimplementierungen der Firmware liegen offen und sind somit für jeden Hard- und Softwareentwickler einsehbar. Hier liegen insbesondere für die Industrie enorme Vorteile, da damit die gesamte darin enthaltene Software leicht wartbar und portabel auf die unterschiedlichsten Plattformen wird. HW- und Software Entwicklung und Erweiterung wird um vieles einfacher. HW-Hersteller können damit Neuentwicklungen schnell und mit wenig Aufwand problemlos und portabel in viele Plattformen integrieren.

Die neue UEFI Schicht

UEFI Name und Bedeutung

Der Name UEFI (Unified Extensible Firmware Interface) steht für eine Interface Specification, welche eine Abstraktionsschicht zwischen BIOS und Betriebssystem beschreibt. Mit ganz einfachen Worten, eine Spezifikation für einheitliche und erweiterbare Firmware Schnittstellen zwischen BIOS und Betriebssystem.

UEFI ist aber nur eine von zig zusammengehörigen und aufeinander aufbauenden Einzel-Spezifikationen, die den Industriestandard für die Firmware des UEFI-BIOS beschreiben. Sie ist aber die markanteste und mächtigste, und deshalb ist sie oftmals auch namens gebend für die Gesamtheit der Firmware und vieler Funktionen.

UEFI oder EFI

UEFI ist eine Weiterentwicklung der ca. 2001 von Intel entwickelten EFI Spezifikation Version 1.10
Bei Version 2.x sprechen wir von UEFI und Version 1.x von EFI. Da viele Funktionen und Grundzüge aber schon in der ersten Generation bei EFI beschrieben wurden und immer noch so auch in den neuen UEFI gelten, wird bei vielen Dingen auch heute oftmals von z.B. EFI-Funktionen und ähnlichen mehr gesprochen, man muss hier nicht allzu strenge Wortbezeichnungen unterscheiden. Aktuell ist heute UEFI, und wenn irgendwo etwas von EFI steht, hat es maximal zu bedeuten, dass es diese Funktion oder was auch immer schon früher bei EFI auch gegeben hat.

Was macht UEFI

Zum Ende der HW-Initialisierung werden die ermittelten HW-Gegebenheiten an UEFI übergeben und dessen Funktionen gestartet. UEFI selbst ist vergleichbar mit einem kleinem Betriebssystem, bestehend aus ein paar Core-Elementen und einer Vielzahl von Hard- und Softwaretreibern. Beim Start werden benötigte Treiber geladen, binden sich an ihre definierten Schnittstellen und bilden neue Schnittstellen für weitere höhere Treiber. Es entstehen genau wie im Linux-Kernel auch komplexe Treiberhierachien, die höhere Protokolle und Services zur Verfügung stellen, welche aus Applikationen direkt angesprochen werden können. UEFI umfasst weiterhin auch den Bootservice, der einen Bootloader startet. Nach dem Start des Betriebssystems werden anschließend die jetzt nicht mehr benötigte UEFI-Elemente wieder aus dem Hauptspeicher entfernt. Andere Funktionen und Treiber bleiben aber aktiv und bilden auch zur Laufzeit des Betriebssystems die Schnittstellen für das Betriebssystem und die dortigen Applikationen.

Als Beispiel hier ein kleiner Auszug aus einer Treiberhierachie, wie sie vom UEFI erzeugt wird.

Ctrl[32] PciRoot(0x0)
   Ctrl[8C] PciRoot(0x0)/Pci(0x0,0x0)
   Ctrl[8D] PciRoot(0x0)/Pci(0x1,0x0)
     Ctrl[9C] PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)
       Ctrl[A2] PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)
         Ctrl[A3] PC-ANSI Serial Console
           Ctrl[59] Primary Console Input Device
           Ctrl[5A] Primary Console Output Device
           Ctrl[5B] Primary Standard Error Device

• am PCI-Bus #0 wurde ein Treiber geladen
• am PCI-Kanal #1 wurde die serielle Schnittstelle #0 gefunden und auch ein Treiber geladen
• auf diesem wurde ein UART Treiber geladen und mit 115200,8,N,1 initialsiert
• auf diesen Treiber hat sich ein ANSI-Console-Treiber gesetzt
• und dieser hat 3 Treiber für Standard EIN- AUS- und FEHLER-Ausgabe gestartet

In Summe wurde hier von UEFI an der seriellen Schnittstelle #0 eine Konsole geladen mit den 3 Standardkanälen, fertig zur Nutzung.

Möglichkeiten und Erweiterbarkeit von UEFI

Der UEFI arbeitet nicht nur intern ähnlich wie ein Kernel und stellt uns ähnlich komplexe Schnittstellen zur Verfügung. UEFI kann auch Applikationen starten. Eine Applikation ist vereinfacht nur ein Bootloader, der kein Betriebssystem startet, sondern einen Programm abarbeitet und sich dann wieder beendet. Applikationen sind hier z.B. das UEFI-Setup, welches hier mit Hilfe der Schnittstellen des BIOS auch in hochauflösender Grafik und mit Mausunterstützung ausgestattet werden könnte. Eine ebenfalls spezifizierte Applikation ist die EFI-Shell, mit der z.B. Wartungsarbeiten und Konfigurationen ausgeführt werden können. Die HW-Hersteller können hier spezielle Applikationen zur Verfügung stellen, z.B. um Raidkontroller zu konfigurieren oder für die Konfiguration der Lüftersteuerung und Stromverbrauch oder Tuning. Die Möglichkeiten sind hier vielfältig.

Im UEFI-BIOS wird vom Hersteller ein meist ausreichender, vollständiger Treibersatz vorhanden sein, der ausreicht um z.B. von Festplatten, DVDs , Floppy, USB usw. zu booten, sowie auch ein Netzwerk-Stack, also alle Treiber, die notwendig sind um den Rechner im UEFI schon netzwerkfähig zu machen und damit z.B. auch schon aus dem UEFI von der Herstellerseite die neuste UEFI-BIOS-Firmware herunterladen zu können, oder um den Rechner über das Netz zu booten. Es können auch weitere Treiber geladen werden, die sich in einem VFAT-Verzeichnis irgendwo auf dem Rechner befinden. Dieses ist möglich, da alle Schnittstellen fest definiert sind und somit externe Entwickler universell einsetzbare Treiber entwickeln können , die dann vom UEFI geladen werden können und zusätzliche Funktionen und Schnittstellen zur Verfügung stellen. Beispiel sind hier z.B. Dateisystemtreiber, die es in der Zwischenzeit schon für fast alle Dateisysteme aus der Linux-Welt gibt. Damit kann UEFI dann nicht nur von VFAT Dateisystemen lesen, sondern auch von Reiserfs, ext2/3/4, btrfs, NTFS und vielen mehr. Die theoretischen Erweiterungsmöglichkeiten sind beim UEFI schier grenzenlos.

Unterschied der Schnittstellen BIOS / UEFI-BIOS

Der BIOS hat seit Anbeginn eine Reihe von sehr einfachen fest definierten Schnittstellen zur Hardware. Damit ist es z.B. möglich, bestimmte Geräte zu resetten oder in einen bestimmten Zustand zu versetzen, einzelne 512 Byte großen Blocke von Festplatte oder Floppy zu lesen oder schreiben, Tastatureingaben entgegen zu nehmen und Zeichen auf den Bildschirm zu schreiben. Ebenso sind auch einfache Funktionen der Grafikkarte möglich, z.B. einen bestimmten Bildpunkt zu setzen usw. Alle diese Funktionen sind fest definiert und sehr einfach zu programmieren und auch vorhanden, wenn das Betriebssystem geladen ist. Der Bootloader benötigt solche Funktionen z.B. um erst einmal den Kernel vom der Platte zu lesen, und der BIOS intern verwendet diese Schnittstellen ebenfalls für seine Aufgaben, zB für das Betreiben des Setupmenus. In der Anfangszeit des PC zu DOS-Zeiten waren dieses auch die einzigen Schnittstellen, die das Betriebssystem nutzen konnte. Noch heute nutzen einfache Betriebssysteme diese als einzigen Schnittstellen zur Hardware, z.B. um mit einem DOS ein Firmware Update von USB-Stick durchzuführen.

UEFI bildet mit seinen Treibern komplexe Schnittstellen zur Hardware und darauf aufbauender Softwaretreibern analog denen eines modernen Betriebssystems. Intern verwendet UEFI eine Reihe von als "Variablen" bezeichnete Elemente zu Speicherung von Einstellungen und ähnlichem. Treiber und damit die Schnittstellen dieser Treiber, ebenso die Variablen werden nach dem Einleiten des Bootvorganges entfernt, oder sie sind auch noch vorhanden, während das Betriebssystem läuft. Diese kann durch entsprechende Eigenschaften der Treiber und durch UEFI-Variablen definiert werden. Andere Schnittstellen zum Betriebssystem wie sie auch im BIOS vorhanden sind, z.B. für HW-Funktionen wie Powermanagement u.Ä. sind im UEFI neu definiert und haben ein anderes Schnittellenformat als die des BIOS.

Unterschied beim Laden des Betriebssystems

Der BIOS beginnt den Start des Betriebssystems in dem er von Floppy, CD/DVD oder Harddisk aus dem MBR oder der primären Partition mit dem Bootflag die ersten 440 Byte in den Speicher lädt und die Ausführung dieses Codes startet. Dort muss sich dann ein Bootloader befinden, der seinerseits genau wissen muss, wie der das Betriebssystem startet und wo und wie der die Dateien dazu findet. Es ist pro Gerät nur immer eine Bootmöglichkeit vorhanden. Sobald der BIOS einen Bootloader gefunden, in den Speicher geladen und gestartet hat, ist seine Aufgabe beendet. Der BIOS kann nicht erkennen ob das Booten funktioniert oder nicht und kann darauf auch nicht reagieren. (möglich nur über abfragen nach einer Zeitspanne ob ein dafür definiertes Bit vom Betriebssystem im BIOS gesetzt ist.) Dabei kann das BIOS direkt nur von Geräten booten, die an Kontrollern des Systemboard angeschlossen sind. Beim Booten über Zusatzkarten muss dieses vom BootBIOS der Kontrollerkarte übernommen werden, und beim Netzwerkboot muss der BootBIOS der Netzwerkkarte vollkommen selbstständig das herunterladen, in den Speicher schreiben und starten des Bootloaders übernehmen. Der BIOS kann nur zum Booten auf den Bootbios der Erweiterungskarte schalten. Die Bootauswahl kann nur im Setup-Menü vorgenommen werden und besteht darin, maximal 4 Geräte in eine Reihenfolge zu sortieren, in der der BIOS versuchen soll, einen Bootloader zu finden.

Der UEFI kann per default Dateien auf VFAT Dateisystemen lesen und schreiben (wenn entsprechende Treiber geladen sind auch Dateien von anderen Dateisystemen lesen). Dateien mit dem Prefix ".efi" sind für UEFI als ausführbarer Code gekennzeichnet. Das können Treiber, Applikationen oder auch Bootloader sein. Diese Dateien kann UEFI in den Hauptspeicher laden und starten. Dabei spielt es keine Rolle ob diese Datei ein Bootloader eine Applikation oder gleich der Kernel des Betriebssystems ist, solange diese Datei vom UEFI lesbar ist, das richtige Binär-Format hat und den Prefix ".efi" tragt, kann UEFI diese Datei im Speicher starten. Dieses passiert auch beim Einleiten des Bootvorganges mit einem Bootloader der sich auf der EFI-Partition befindet. Es können dort in diesem Dateisystem mehr als nur ein einziger Bootloader befinden. Welcher bootloader per default als erster ausprobiert wird, ist in Bootvariablen definiert. Diese Bootvariablen können sowohl im Setup Menü, in der EFI-Shell als auch vom Betriebssystem aus angelegt und konfiguriert werden. Darüber hinaus ist es meist aus dem SetupMenü oder dem Bootauswahlmenü möglich unabhängig von der Reihenfolge in der Bootvariable einen bestimmten Bootloader auszuwählen. Ebenso ist es möglich aus der EFI-Shell die Ausführung eines Bootloader manuell oder per Script zu starten, auch wenn dieser gar nicht im den Bootvariablen vorhanden ist. Funktionieren alle in den Bootvariablen definierten Bootloader nicht (zB. weil nach einem Firmwarereset alle Variablen gelöscht worden sind), dann gibt es auch noch einen Fallback, einen definierter Dateinamen in einem bestimmten Verzeichnis, wo in diesem Fall UEFI dann nach einem dort hinterlegten Bootloader sucht, und diesen dann starten würde. Dieses ist auch die Methode welche zB. für das Booten von CD/DVDs genutzt wird. Die Möglichkeiten den Start des Bootvorganges einzuleiten sind hier also vielfältig. UEFI ist nach dem Start des Bootloaders auch noch nicht fertig, für ihn ist der Bootprozess erst eingeleitet wenn ihm der Bootloader das durch ausführen einer bestimmten Funktion bestätigt. Kommt die Bestätigung das das Betriebssystem gestartet ist, dann werden vom UEFI alle Ressourcen (zB. geladene Treiber, Variablen) aus dem Speicher entfernt die gekennzeichnet sind nur während der Bootphase vorhanden zu sein.

UEFI ist, da er einen eigenen Netzwerkstack hat oder haben kann, auch in der Lage selbstständig einen Netzwerkboot auszuführen, wenn dieser entsprechend konfiguriert ist. Dabei könnten (vorausgesetzt die entsprechenden Treiber sind im UEFI geladen und konfiguriert) verschiedensten Protokolle zum Einsatz kommen, unabhängig ob auf den Netzwerkkarten ein Bootbios vorhanden ist, und welche Protokolle sich dort befinden.

Unterschied bei den Setup Menüs

Beim BIOS gibt es ein Setup Menü fest im der BIOS-Firmware integriert und erreichbar mittels definiertem Tastendruck bei Startvorgang. Die Anzeige ist eine einfach VGA Text-GUI. Bedienung erfolgt mit den Funktions- und Cursortasten. Je nach BIOS-Hersteller hat sowohl Aussehen und Menüpunkte ein typisches Erscheinungsbild. Die Sprache immer Englisch, die Benennung der einzelnen Menüpunkte und Funktionen nicht immer viel sagend und treffend. Aber da sich das über viele Jahre nie großartig geändert hat, hat wohl der Gewöhnungeffekt dazu geführt, das man sich meist gut zurecht gefunden hat.

Beim UEFI-BIOS ist dieses eine Applikation die Bestandteil der Firmware ist und es gibt keinerlei Definition wie dieses Setup Menü aussehen muss. Jeder Hersteller kann (und tut dieses auch) das Aussehen nach seinen Vorstellungen gestalten und es ist auch möglich das mehrere Erscheinungsbilder dafür in der BIOS-Firmware integriert sind. (zB. Textmodus und Grafikmodus) Die Möglichkeiten sind vielfältig und gehen vom ganz einfachen Textmenü, über Simulationen eines alten BIOS-Setup-Menü mit gewohnter einfacher Tastatursteuerung bis hin zu multilingualen modernen Grafischen Menüs mit voller Mausunterstützung und allerlei Schnickschnack. Auch die Einteilung der Menüs, die Gesamtheit der Möglichkeiten und Funktionen sowie die Benennung der einzelnen Menüpunkte und Funktionen sind nicht standardisiert und leiden oft auch noch im multilingualem Umfeld an seltsamen Übersetzungen.

Kompatibilität zum BIOS

Für die Abwärtskompatibilität des UEFI existiert auf x86 basierenden Architekturen die Möglichkeit des Booten im Legacy-BIOS-Modus von MBR-partitionierten Festplatten. (CSM Compatibility Support Module). In diesem Szenario wird das Booten in der gleichen Weise wie mit BIOS üblich ermöglicht. Auch die BIOS typischen Schnittstellen werden nach dem Booten dann für das Betriebssystem simuliert. Diese Funktion ist oftmals im Setup fest einstellbar. Möglich aber auch UEFI Implementierungen die sich anhand der vorhanden Partitionen oder eines vorhanden Bootloaders im MBR der Platte entscheiden mit welcher Methode von dieser Platte gebootet werden soll. Auch von GPT Platten kann theoretisch Legacy boot ausgeführt werden. Ein Bootloader im MBR einer GPT partitonierten Platte kann jedoch bei einigen UEFI Implementierungen, obwohl in UEFI eigentlich eine vollständige MBR-Partitionstabellen unterstützt werden sollten, ein Booten von UEFI verhindern.

Secure Boot

Die Arbeitsweise des UEFI, die theoretischen Möglichkeiten mit dieser grenzenlosen Erweiterbarkeit, dem integriertem Netzwerkstack und der Möglichkeit hier schon vor dem Betriebssystem Software zu starten welche auch unbemerkt unterhalb des Betriebssystems weiterlaufen kann, stellt ein beträchtliches Sicherheitsrisiko dar. Zumal für den Normalen PC oder Rechnerbenutzer dieser Bereich immer eine Blackbox bleiben wird, und der User sich wegen der langen Erfahrungen mit dem dummen BIOS hier wohl derzeit auch wenig Gedanken über solche Sicherheitsprobleme dort macht.
Um hier an dieser Stelle eine möglichst große Sicherheit und Kontrolle einzubauen, gibt es ab UEFI-Version 2.3.1 Secure Boot. Das Prinzip dahinter, UEFI darf nur Bootloader, Treiber, Applikationen und andere Erweiterungen in den Speicher laden und starten, wenn diese von einer Zertifizierungsstelle signiert ist und das dazu passende öffentliche Zertifikat im UEFI vorhanden ist. Diese Zertifikate im UEFI sind so geschützt, das es praktisch nur dem Hersteller der Hardware und (heute) Microsoft gestattet ist, dort Zertifikate abzulegen, und auch nur diesen möglich ist mit den dazu passenden privaten Schlüsseln UEFI Software zu signieren. (mehr dazu im Secure Boot Artikel.

Angestrebte Ziele von UEFI

• Einfache Erweiterbarkeit (sowohl in unterstützter HW als auch an Software)
• Eingebettetes Netzwerkmodul (möglich zB für Fernwartung und Überwachung)
• Preboot Execution Environment (universelle Netzwerkboot Schnittstelle)
• Hochauflösende Grafikkarten schon vor dem Start des Betriebssystems
• Multilinguale Tools (Ausgabe und Tastatur in Landessprache des Users in UEFI-Apps)
• BIOS-Emulation (für Kompatibilität zu alten Betriebssystemen) (CSM)
• EFI-Shell (als Wartungs- und Reparaturtool, kann mit seinen Möglichkeiten noch heute gebrächliche DOS-Lösungen ersetzen)
• Möglichkeit auch systemunabhängige Treiber (für spezielle HW einen Uefi Treiber nutzbar aus allen BS)
• eigene UEFI Bootloader Konfiguration (externe Boot-Loader eigentlich überflüssig)
• Unterstützung von GUID Partition Table (GPT)
• Unterschiedlichen HW-Plattformen (CPU-Architekturen) und dafür weitestgehend nur einem UEFI-Software-Quellcode