Bereits seit 1982 übernimmt das BIOS grundlegende Initialisierungs- und Konfigurationsfunktionen beim Einschalten eines PCs, um anschließend diese Daten an das Betriebssystem zu übergeben. Mit dem Extensible Firmware Interface (EFI) als eine Art Minibetriebssystem will Intel diesen Bereich modernisieren.
Dabei ist EFI kein BIOS im herkömmlichen Sinne, sondern eine Industrie-Interface-Spezifikation, die als Schnittstelle zwischen der Hardware-Firmware und dem Betriebssystem fungiert. EFI benötigt nur rudimentären Firmware-Support. Die Beschreibung der Hardware-Eigenschaften erfolgt nicht mehr im BIOS oder in Betriebssystemtreibern. Der jeweilige Hersteller muss diese größtenteils in EFI-konformen Treibern zur Verfügung stellen.
Dadurch kann das EFI-System als "kleines Betriebssystem" in der Pre-Boot-Phase dienen und wichtige Test-, Diagnose- und Konfigurationsfunktionen übernehmen, ohne das Betriebssystem zu laden. Diese Funktionen vereinfachen auch die Analyse von Fehlermeldungen und erleichtern die Abfrage des Systemstatus bei defekten Rechnersystemen.
Die EFI-Architektur kommt bereits in Itanium-basierenden Systemen (IA64) zum Einsatz, soll aber mit der Einführung von Longhorn 2006 auch im Server-, Workstation- und Desktop-Bereich in IA32- beziehungsweise IA32E-Architekturen eingeführt werden. Zusätzlich will Intel die Portierung von EFI durch das "Intel Platform Innovation Framework for EFI" vereinfachen. Im folgenden Artikel beschreiben wir, welche Neuerungen die EFI-Technologie und das Framework bieten.
Was ist EFI?
EFI steht für Extensible Firmware Interface und ist eine Industrie-Interface-Spezifikation, die ein Industriekonsortium unter der Federführung von Intel und Microsoft entwickelt. Es definiert eine vereinfachte Zusammenarbeit zwischen dem Betriebssystem und der Firmware. Zu den Vorzügen von EFI gehören eine einheitliche Spezifikation, einfache Erweiterbarkeit und höhere Flexibilität gegenüber der herkömmlichen BIOS/OS-Architektur. Zusätzlich ermöglicht EFI, die Hardware ohne Hilfe des Betriebssystems zu testen. Darüber hinaus lässt sich die Technologie auf multiple Plattformen wie Server, Workstations oder Desktops mit unterschiedlichen Betriebssystemen portieren.
Die EFI-Technologie stellt keinen Ersatz für ein Betriebssystem oder eine hochleistungsfähige Betriebsumgebung dar. Sie soll nicht die bestehenden Systeme mit PC/AT-Firmware ersetzen, sondern dazu kompatibel sein. Erst mit der Einführung des Longhorn-Betriebssystems 2006 soll EFI zum allgemeinen Standard werden.
Um in der Pre-Boot-Phase die Kontrolle über die Hardware-Komponenten zu übernehmen, und diese an das zu bootende Betriebssystem zu übergeben, stellt die EFI-Architektur eine Umgebung zur Verfügung. Sie ist aber weder mit einer speziellen Firmware-Version gleichzusetzen, noch mit einer kompletten Runtime-Plattformspezifikation vergleichbar.
Zu den weiteren Eigenschaften von EFI zählen verbesserte Bootoptionen durch Änderung der Festplatten-Infrastruktur mittels des GPT-Disc-Formats. Zusätzlich bietet EFI vollen Unicode-Support und nahezu uneingeschränkte Erweiterbarkeit des Firmware-Modells durch 32/64-Bit-Programmierung in der Hochsprache C. Bisher mussten die Firmware-Entwickler mit Assembler im 16 Bit Real Mode vorlieb nehmen. Darüber hinaus ist die Preboot-Execution-Environment-Technologie (PXE) fester Bestandteil der EFI-Architektur. Sie arbeitet unabhängig von Network-Interface-Card-Treibern (NIC) bestimmter Hersteller.
EFI-Designkonzept
Das EFI-Design basiert auf vier grundlegenden Elementen. So müssen bestehende Interfaces, die bereits auf Intel-Architekturplattformen vorhanden sind, weiter von den EFI-Spezifikationen unterstützt werden. Zusätzlich nutzt EFI das GPT-Disc-Format, um die volle Funktionalität zu garantieren.
Darüber hinaus stellen Bootservices Interfaces zur Verfügung, die in der Pre-Boot-Phase auf Geräte- und Systemfunktionen zugreifen können. Der Zugriff erfolgt abstrakt über Protokolle und so genannte Handles. Diese Methode gewährleistet die Abwärtskompatibilität zu den BIOS-Code-basierenden Systemen. Zusätzlich stellen die Runtime Services dem Betriebssystem einen minimalen Satz an Laufzeitfunktionen, wie etwa Zugangskontrolle oder Systemsicherheitsfunktionen, zur Verfügung, die das OS während seines Normalbetriebs benötigt.
Eine rudimentäre Plattform-Firmware (ähnlich einem einfachen BIOS) ist in der Lage, ein EFI-Betriebssystem-Loader-Image über unterschiedliche Speichermedien wie Festplatte, CD-ROM oder Netzwerk zu laden. Durch die Erweiterbarkeit des Protokoll-Interfaces können auch weitere Bootmedien, die auf einem abweichenden Protokoll basieren, problemlos in das EFI-System integriert werden.
Ist der OS-Loader aktiviert, beginnt dieser, das komplette Betriebssystem zu laden. Dazu benötigt der OS-Loader die EFI-Bootservices und die dazugehörenden Interfaces. Dieser analysiert und initialisiert die verschiedenen Plattformkomponenten und übergibt anschließend die Verwaltung dieser Komponenten an das Betriebssystem. Zusätzlich stehen dem EFI-OS-Loader während der Bootphase die Runtime Services zur Verfügung.
EFI-Treibermodell: Einsatzgebiete
Eine Hauptaufgabe des EFI-Models besteht in der Vereinfachung des Designs und der Implementierung von benötigten Gerätetreibern in Form von kleinen ausführbaren Images. Deshalb haben die Entwickler einen Teil des Geräte- und Bustreiber-Codes ins EFI-BIOS integriert. Einen großen Anteil an der EFI-BIOS-Architektur übernehmen so genannte Firmware Services, die unabhängig vom Betriebssystem auf die installierte Hardware zugreifen. Sie können ohne Hilfe des Betriebssystems bestimmte Test- und Diagnosefunktionen ausführen.
Ein PC-System besteht in der Regel aus ein oder mehreren Prozessoren, die über entsprechende Chipsätze angesteuert werden. Der Chipsatz wiederum benötigt Busstrukturen, um Daten von und zu den Controllern sowie Geräten zu transportieren.
Das EFI-Treibermodell versucht nicht, den Prozessor oder den Chipsatz zu beschreiben, sondern begnügt sich mit der Beschreibung der Controller und der Geräte sowie der verschiedenen Bussysteme. Diese Komponenten sind mit einer Baumstruktur vergleichbar - mit dem Chipsatz als Wurzel.
Um eine möglichst hohe Interoperabilität zwischen Firmware-Services, Bus- und Gerätetreibern zu gewährleisten, wird vorausgesetzt, dass alle Hersteller EFI-konforme Komponenten bereitstellen. Diese müssen sich exakt an die EFI-Richtlinien wie den Einsprungpunkt eines Treibers oder Host-Bus-Controllers, die Eigenschaften eines Geräte- oder Bus-Controllers sowie an das Handling von Hot-Plug-Ereignissen halten.
EFI-Bootmanager
EFI erweitert die bestehende Plattform-Firmware, indem es entsprechende EFI-Treiber- und Applikations-Images lädt. Wenn die EFI-Anwendungen und Treiber geladen sind, haben diese Zugang zu allen EFI-definierten Laufzeit- und Bootservices.
EFI vereinfacht das Handling in der Startphase, indem es Bootmenüs des Betriebssystems und der Firmware in einem einzigen Plattform-Firmware-Menü vereinigt. Dieses EFI-Menü erlaubt es, einen beliebigen Betriebssystem-Loader auf einer frei wählbaren Partition eines beliebigen Bootmediums zu benutzen. Zusätzlich ist es mit EFI möglich, weiterhin Legacy-Bootoptionen zu verwenden, wie zum Beispiel das Booten vom Laufwerk A: oder C: über die herkömmliche Firmware beziehungsweise das BIOS.
Die EFI-Firmware kann von Laufwerken booten, die entweder über einen EFI-OS-Loader oder über eine EFI-konforme Systempartition verfügen. Letztere ist notwendig, um von willkürlichen Block-Devices zu booten. Da EFI keine Änderungen am ersten Sektor der Partition vornimmt, ist es möglich, sowohl von Legacy- als auch von EFI-Laufwerken zu starten. Als Block-Device werden normalerweise Festplatten mit MBR- oder GPT-Struktur, oder entsprechende Wechsellaufwerke wie LS120 oder ZIP-Drives bezeichnet.
GPT-Format
Mit der Einführung des Longhorn-Betriebssystems und EFI ändert sich auch die bestehende Festplatten-Partitionierung. Das GUID-Partition-Table-Format ersetzt das veraltete Master-Boot-Record-Format (MBR) und hebt die bisherigen Einschränkungen dieser Technologie auf. Allerdings gewährleistet GPT durch einen "Dummy-MBR" die Abwärtskompatibilität.
So adressiert die Global Universal Identification (GUID) Partition Table durch den Support der 64-Bit-LBA-Adressierung Festplatten bis zu einer Größe von 18 ExaByte und bis zu 128 primäre Partitionen auf einem Laufwerk. Zusätzlich legt es neben der primären auch eine redundante Backup Partition Table zur Sicherheit an.
Dagegen kann eine MBR-Festplatte maximal vier primäre Partitionen oder drei primäre und eine erweiterte Partition verwalten. Die Anzahl der logischen Laufwerke in der erweiterten Partition wird durch die alphabetische Kennzeichnung (26 Buchstaben) eingeschränkt.
Ein weiterer Vorteil der GPT-Laufwerke besteht darin, dass die Partitionen keinen ausführbaren Bootcode enthalten, sondern nur reine Daten verwalten. Dies vermindert Virusattacken durch Bootcode-Manipulationen. Um eine Bootanwendung auf einem GPT-Laufwerk zu starten, benötigt die EFI-Technologie das erweiterte EFI-Treibermodell und den EFI-Bootmanager sowie eine EFI-Systempartition (ESP), auf der EFI-spezifische Treiber abgelegt werden können. Der Bootmanager lokalisiert auf dem Datenträger den entsprechenden Datenblock - ähnlich eines Mount-Points bei Linux - und startet das Programm.
EFI-Treiberinitialisierung
EFI-Treiberdateien oder Images können von unterschiedlichen Medien wie ROM, Flash-Speicher, Festplatten, Floppy-Laufwerken, CD-ROMs oder auch Netzwerkverbindungen geladen werden. Nachdem das System ein Treiber-Image auf einem Medium lokalisiert, lädt es dieses in den Systemspeicher. Dabei initialisiert EFI einen so genannten Image Handle, der die Loaded-Image-Protokoll-Instanz verwaltet. Zu diesem Zeitpunkt ist der geladene Treiber noch nicht aktiv.
Nach dem Laden des Treiberabbildes auf den Image Handle startet EFI den Treiber mit dem Bootservice-Befehl StartImage(). Er erzeugt in dieser Phase ein Driver-Binding-Protokoll auf den Image Handle. Für Zusatzfunktionen kann EFI optional ein Configuration- und ein Diagnostic- sowie ein Component-Name-Protokoll auf dem Handle anlegen.
Nach EFI-Vorgaben unterliegt der geladene Treiber einigen Restriktionen. So darf dieser mit seinem Einsprungspunkt die Hardware nicht beeinflussen beziehungsweise Prozesse starten, sondern sich lediglich in eine Warteposition begeben. Erst eine Plattformkomponente, wie etwa der EFI-Bootmanager, ist in der Lage, dem geladenen Treiber die Anweisung zu geben, einen bestimmten Controller zu verwalten beziehungsweise mit entsprechenden Steuerdaten zu versorgen. Ähnliches gilt auch für die verwalteten Geräte oder Bussysteme.
EFI-Module-Test-Architektur
Einen besonderen Vorteil bietet EFI mit der Module-Test-Architektur (MTA). Diese erlaubt dem Systemhersteller und dem Anwender, Hardware-Komponenten eines Rechnersystems ohne Hilfe des Betriebssystems zu testen. Das ist heute zum Beispiel in der Windows-Umgebung nur mit BIOS/DOS-basierenden Funktionen möglich. Zu den Einschränkungen zählen die begrenzte Verwaltung von Festplatten und fehlendes Remote-Netzwerk-Management sowie fehlendes grafisches Interface.
Deshalb stellt EFI für Test- und Diagnosezwecke ein eigenes grafisches User Interface (EFI-Shell) parat. Mit Hilfe von spezifischen Toolkits bietet EFI den Entwicklern die Möglichkeit, Test-Scripts und -Libraries in der Hochsprache C zu programmieren. Ein weiterer Vorteil der EFI-MTA besteht darin, dass alle Bestandteile der modularen Testarchitektur wie Script Interpreter, Toolkits und Shells systemübergreifend eingesetzt werden können.
Neu: Intel Innovation Framework für EFI
Wie bereits erläutert, benötigt das EFI-Konzept entsprechenden Betriebssystem-Support inklusive der modularen Interfaces, um das konventionelle BIOS zu ersetzen. Um die Übergangsphase auf EFI-basierende Systeme zu vereinfachen, rief Intel das Platform Framework für EFI ins Leben. Zusätzlich erfüllt das Framework das Verlangen vieler Systemintegratoren nach Abwärtskompatibilität zu bestehender BIOS-Firmware beziehungsweise zu Betriebssystemen.
Das Framework besitzt eine modulare Architektur und besteht aus Low-Level-Framework-Treibern. Einen weiteren zentralen Bestandteil des Frameworks bildet der so genannte Foundation-Code. Dieser steht jedem Hersteller als Open-Source-Code zur Verfügung. Das Framework beinhaltet nicht nur EFI-Komponenten, sondern bietet umfangreiche Zusatzfunktionen. Dazu zählen firmenspezifische Pre-Bootoptionen und Fehleranalyse per Remote-Zugriff. Darüber hinaus bietet es Abwärtskompatibilität zu herkömmlichen Betriebssystemen, durch Umgehung von EFI mittels eines Compatibility-Support-Moduls (CSM).
Neu: Compatibility-Support-Modul für EFI
Im Gegensatz zu EFI garantiert das Framework per optionalem Compatibility-Support-Modul, die Kompatibilität zu herkömmlichen BIOS-Interfaces und Betriebssystemen herzustellen. Mit dem CSM soll es unter EFI weiterhin möglich sein, Legacy-Optionen zu verwenden. Dazu zählt zum Beispiel, Interaktionen im 16-Bit-Real-Mode durchzuführen, direkt Interrupt-Service-Routinen (INT19, INT13) aufzurufen oder entsprechende Legacy-Option-ROMs zu laden. Das bedeutet: Nur in Verbindung mit CSM ist eine Zusammenarbeit von Legacy-Hardware beziehungsweise konventionellen Betriebssystemen mit EFI-Technologie möglich.
Das CSM bietet gerade in der Übergangszeit von Legacy-BIOS zu EFI wichtige Vorteile wie modularen Aufbau und einfache Portierbarkeit. Es nutzt die Framework-Platform-Initialisierungsroutinen und stellt EFI-Post-Replacement und -ACPI-Code zur Verfügung. Damit entfallen umständliche Entwicklungen von neuen Programm-Modulen.
Die Implementierung des CSM ins Framework greift in mehrere Bereiche des PC-Systems ein. Bereits in der Initialisierungsphase eines Rechners umgeht das Pre-CSM die standardmäßige Pre-EFI-Initialisierung (PEI). Im Driver Execution Environment (DXE), in dem alle wichtigen Treiber und Protokolle für das System hinterlegt sind, extrahieren und erzeugen die Legacy-32-CSM-Treiber alle wichtigen Daten, die für das Legacy-16-BIOS notwendig sind. Zusätzlich greift ein Boot-Device-Selection-CSM (BDS-CSM) in die Kontrolle der herkömmlichen Boot Selection und in die Steuerung des Legacy-Boot-Control-Managers ein.
Neu: EFI in der Praxis
Für die Integration von EFI in zukünftige Rechnersysteme bietet der amerikanische BIOS-Firmware-Entwickler American Megatrends bereits einsatzfähige Lösungen an. Mit Aptio stellt AMI eine Firmware zur Verfügung, die auf Intels Platform Innovation Framework für EFI basiert.
Das Aptio-BIOS beinhaltet neben Entwicklungs-Applikationen wie Visual eBIOS und AMI Debug für EFI zusätzliche Support-Utilities wie AMI Flash Utility Suite, Change Logo Utility und SMBIOS Data Management. Um das System zu konfigurieren, stellt AMI eine grafische Setup-Umgebung inklusive grafischem Boot-Manager zur Verfügung. Darüber hinaus integrierten die BIOS-Entwickler ein Compatibility-Support-Modul (CSM), das die Kompatibilität zum Legacy AMIBIOS8 gewährleisten soll. Eine AMI-PreBoot-Application-Umgebung, die Pre-Boot-Anwendungen in geschützten und versteckten Partitionen ausführen und speichern kann, rundet das Angebot der Aptio-EFI-Firmware ab.
Eine weitere praktische Anwendung für EFI präsentierte Hitachi auf dem Intel Developer Forum Spring 2005. Der Hersteller demonstrierte ein System, basierend auf den Vanderpool unterstützenden Itanium 2 "Montecito", das mittels EFI-Technologie und entsprechender VM-Software mehrere Virtual-Machines erzeugt. Die VM-Applikation wird als EFI-kompatibles Programm einfach in das EFI-BIOS geladen - das Host-Betriebssystem entfällt.
Sowohl im Business- als auch im Consumer-Segment existieren zahlreiche Anwendungsszenarien für Virtualisierung - beispielsweise für die Migration von einem Betriebssystem zu einem anderen.
In einer VM lassen sich die verwendeten Programme ohne Gefahr mit dem neuen OS testen. Anwendungen, die auf dem neu einzusetzenden Betriebssystem nicht laufen, arbeiten einfach in einer eigenen VM mit dem bisherigen OS weiter. Bei Desktop-PCs im Consumer-Segment wären eigene hoch abgesicherte Installationen für den Internet-Zugriff möglich.
Update: Fazit und Ausblick
Intels Extensible Firmware Interface hebt einige Restriktionen der in die Jahre gekommenen Schnittstelle zwischen BIOS und Betriebssystem auf und verspricht schnelleres Booten, bessere Handhabung und umfangreiche Zusatzfunktionen.
EFI stellt eine neue flexible Schnittstelle zwischen der Plattform-Hardware und dem Betriebssystem dar. Der modulare und systemübergreifende Aufbau von EFI ermöglicht Hardware-Herstellern, entsprechende Treiber nach EFI-Standard zu programmieren, ohne auf bestimmte Systemeigenschaften Rücksicht zu nehmen.
Ein wichtiger Bestandteil von EFI sind spezielle Diagnose- und Testfunktionen der Hardware, die diese Architektur unabhängig vom Betriebssystem bereitstellt. Zusätzlich unterstützt EFI die mit Longhorn kommende GPT-Festplatten-Partitionierung. Es ist frei von bisherigen Restriktionen durch das BIOS beziehungsweise Betriebssystem in Bezug auf Verwaltung, Partitionierung und Kapazitätseinschränkungen.
Laut Intel ist EFI für die 64-Bit-Itanium-Architektur zurzeit die einzige Alternative, ein entsprechendes System zu betreiben. Mit Einführung von Longhorn 2006 soll EFI auch in IA32- und IA32E-Architekturen Einzug halten und somit das herkömmliche BIOS endgültig ablösen. Allerdings wird die Migration auf EFI-basierende Systeme schleichend erfolgen, da die nötige Infrastruktur erst geschaffen werden muss. Erleichtert wird der Umstieg auf die EFI-Technologie durch das "Intel Innovation Framework for EFI": Es bietet mit einem Compatibility-Support-Modul Abwärtskompatibilität zu bestehenden Systemarchitekturen. (hal)