BIOS (IBM PC)

Flash-ROM mit Award-BIOS

AMIBIOS

Das BIOS [/ˈbaɪ.oʊs/] (von englisch „basic input/output system“) ist die Firmware bei x86-PCs. Es ist in einem nichtflüchtigen Speicher auf der Hauptplatine eines PC abgelegt und wird unmittelbar nach dessen Einschalten ausgeführt. Aufgabe des BIOS ist es unter anderem, den PC zunächst funktionsfähig zu machen und im Anschluss das Starten eines Betriebssystems einzuleiten.

Das BIOS ist heute weitgehend durch Unified Extensible Firmware Interface (kurz EFI oder UEFI) abgelöst.

Aufgabe des BIOS

Ein BIOS löst zwei Probleme, die beim Kaltstart eines PCs auftreten:

• Zum einen löst es durch das sogenannte „Bootstrapping“ ein klassisches Henne-Ei-Problem: Software ist in der Regel auf einem Datenträger gespeichert, welche beim Start zunächst in den Hauptspeicher des Rechners eingelesen werden muss. Zum Einlesen des Datenträgers benötigt die CPU aber wiederum Software. Frühere Computer und Rechenanlagen lösten dieses Problem dadurch, dass sie die CPU nach dem Einschalten des Rechners grundsätzlich zunächst in den Pausemodus versetzten. Bevor der Rechner gestartet werden konnte, musste manuell oder mit Hilfe spezieller Peripherie eine minimale Software (der Bootloader) in den Hauptspeicher geladen werden. Häufig war das Laden des Bootloaders beim Starten des Rechners aber gar nicht nötig, da der in den 1960er und frühen 1970er Jahren weit verbreitete Kernspeicher – im Gegensatz zum heute gebräuchlichen Halbleiterspeicher – seinen Inhalt beim Ausschalten nicht verlor (Persistenzspeicher) und die Programme im Hauptspeicher deshalb zumeist nur neu gestartet werden mussten oder sogar fortgesetzt werden konnten. Das Ladeprogramm ist bei heutigen PCs Teil des BIOS, das in einem speziellen Speicherbaustein, dem EPROM oder bei neueren Modellen meist in einem Flash-Speicher abgelegt ist, deren Speicherinhalt jeweils auch ohne Stromversorgung erhalten bleibt. Beide sind vollständig unabhängig von einer Energieversorgung und auch für die Firmware von portablen Geräten geeignet. Damit entfällt heute die manuelle Eingabe eines Ladeprogramms.
• Zum anderen erfordert unterschiedliche Hardware jeweils eine spezielle Ansteuerungssoftware (Treibersoftware) und die zugehörige Konfiguration. Früher musste ein Betriebssystem auf jede Variante jedes Rechnertyps speziell zugeschnitten werden, um darauf lauffähig zu sein. Durch die Auslagerung dieser speziellen Ansteuersoftware in das BIOS der jeweiligen Rechner wurde es möglich, die gleiche Betriebssystemsoftware auf verschiedenen Rechnern laufen zu lassen. Damit wirkt das BIOS nach neuerer Sprechweise als Hardware Abstraction Layer (HAL). Allerdings benutzen fast alle modernen Betriebssysteme eigene Treiber, vor allem weil die vom BIOS im Protected und Long Mode nicht verfügbar sind. In einem von diesem laufen aber fast alle modernen Betriebssysteme, unter anderem um einen größeren RAM verwalten zu können und um Multitasking einfach zu organisieren.

BIOS beim IBM-kompatiblen PC

Funktionen

Durch modernere Hardware hat das BIOS im Laufe der Zeit neue Funktionen hinzugewonnen. Nicht alle der im Folgenden genannten Punkte wurden schon vom Ur-BIOS auf dem ersten IBM PC ausgeführt. Die Weiterentwicklung der Hardware hat im Laufe der Zeit (Stand 2016 ist das BIOS-Konzept bereits mindestens 41 Jahre alt) zu einer Reihe von iterativen, inkompatiblen Ergänzungen geführt, die zunehmend den Charakter von „Flickschusterei“ tragen und bei 64-Bit-Systemen an ihre Grenzen stoßen. Daher wurde in Form von Extensible Firmware Interface (EFI, bzw. UEFI) ein BIOS-Nachfolger entwickelt.

Ein ROM, auf dem ein BIOS gespeichert ist

Im Wesentlichen führt das BIOS, bevor das Betriebssystem gestartet wird, die folgenden Funktionen aus:

• Power On Self-Test (POST)
• Initialisierung der Hardware

Wichtiger Bestandteil der Hardware-Initialisierung eines Plug-and-Play-BIOS ist die Konfiguration und Überprüfung von eingebauten Steckkarten.

Dazu werden in einem speziellen Speicherbereich des BIOS, dem Bereich Extended System Configuration Data (kurz ESCD), Informationen zu Zustand und Konfiguration von ISA-, PCI- und AGP-Steckkarten und die entsprechende Ressourcenzuteilung verzeichnet. Die Informationen im ESCD-Bereich werden beim Bootvorgang mit dem tatsächlichen Zustand des Systems verglichen und bei Änderungen gegebenenfalls aktualisiert. Das Betriebssystem greift auf die Informationen im ESCD-Bereich zurück und kann Änderungen der Plug-and-Play-Ressourcenzuordnung dort speichern, um Veränderungen durch das BIOS beim nächsten Start vorzubeugen.

Hauptmenü vom Award „BIOS-Setup“

• Aufforderung zur Eingabe eines BIOS-Passworts (falls konfiguriert)
• Aufforderung zur Eingabe eines Festplatten-Passworts (falls konfiguriert)
• Darstellung eines Startbildschirms
• Möglichkeit, ein BIOS-Konfigurationsmenü („BIOS-Setup“) aufzurufen
• Aufrufen von BIOS-Erweiterungen einzelner Subsysteme, die entweder auf Steckkarten untergebracht sind oder direkt auf dem Mainboard integriert sind, z. B.:
  • Grafikchip
  • Netzwerkchip
  • SCSI-Controller
  • RAID-Controller
• Feststellen, von welchem Datenträger gebootet werden kann und soll
• Laden des Bootsektors; meistens ist das ein Bootloader.

Danach übernimmt das Programm im geladenen Bootsektor die Kontrolle über den Rechner. Meist lädt und startet der enthaltene Bootloader das auf dem entsprechenden Datenträger installierte Betriebssystem entweder sofort oder bietet ein Menü zur Auswahl eines Betriebssystems an (Bootmanager). Bei klassischen im Real Mode laufenden Betriebssystemen (z. B. DOS) wird das BIOS auch im weiteren Betrieb genutzt. Es übernimmt für das Betriebssystem die Kommunikation mit diverser Hardware, z. B.:

• Tastatur
• Serielle und parallele Schnittstellen
• Systemlautsprecher
• Grafikkarte
• Diskettenlaufwerke
• Festplattenlaufwerke

Andere, moderne Arten von Hardware werden vom BIOS nicht bedient. Zur Ansteuerung beispielsweise einer Maus ist unter DOS ein spezieller Hardwaretreiber nötig.

Neuere, treiberbasierte Betriebssysteme wie beispielsweise Linux oder Windows nutzen diese BIOS-Funktionen nicht. Sie laden für jede Art von Hardware einen speziellen Treiber. Jedoch müssen sie am Anfang ihres Startvorgangs über den Bootloader noch kurz auf die BIOS-Funktionen zur Ansteuerung der Festplatten zurückgreifen, um ihren Festplattentreiber zu laden.

BIOS-Einstellungen

Um in das Setup-Programm des BIOS zu gelangen, muss beim Einschalten des Rechners eine bestimmte Taste oder Tastenkombination betätigt werden. Bei einigen wenigen Mainboards muss ein bestimmter Jumper gesetzt werden.

Die Einstellungen werden in einem CMOS-Speicher gespeichert, der über die Mainboard-Batterie auch ohne Netzanschluss mit Strom versorgt wird. Oft ist dieser Speicher mit der Echtzeituhr des Systems kombiniert, da auch diese immer mit Strom versorgt werden muss. Bei Schwierigkeiten bietet das BIOS meist die Möglichkeit, die Standardeinstellungen des Rechner- oder des BIOS-Herstellers zu setzen. Wenn es nicht mehr möglich ist, ins Setup-Programm zu kommen (etwa weil der Rechner gar nicht mehr bootet), lassen sich die Einstellungen meist über einen Jumper am Mainboard zurückstellen (bei allen neueren Mainboards muss dafür das Netzteil ganz abgeschaltet werden). Wenn das nicht möglich ist, kann der CMOS-Speicher durch das Entfernen der Batterie gelöscht werden. Letzteres benötigt aber einige Zeit, bis auch die Kondensatoren entladen sind.

Sicherheit

Das BIOS ist die zweite Sicherheitsstufe, die unberechtigten Zugriff auf einen Computer verhindern kann, nach einer physischen Sicherung mit Schlössern oder Ähnlichem. Im BIOS-Setup kann eine Passwortabfrage für das Starten des Rechners eingerichtet werden. Das stellt keine vollständige Sicherung des Systems dar, da die Einstellungen bei physischem Zugang zum Computer mehr oder weniger leicht durch Manipulationen auf der Hauptplatine ausgehebelt werden können. Zudem wirkt diese Sicherung nur auf die Hauptplatine, auf der sich das BIOS enthaltende ROM befindet. Wird diese ausgetauscht oder die Festplatte(n) des Systems in einen anderen Rechner eingebaut, kann problemlos auf alle Daten zugegriffen werden. Zudem haben die Hersteller meist ein festes (Recovery-, Master- oder Supervisor-)Passwort eingerichtet, um den Zugang wiederherstellen zu können, wenn der Benutzer sein eigenes Passwort vergessen hat.

Aktualisieren des BIOS

Bei alten Mainboards (mit 286 bis 486er Prozessor) ist im BIOS die Option „SHADOW BIOS MEMORY“ vorhanden. Dabei wird das BIOS in eigener Prozedur in das zugriffschnellere RAM kopiert (temporäre Schattenkopie bis zum Ausschalten des Computers). Seitdem (ab spätere 486er / Pentium1) der überwiegende Teil des BIOS gepackt abgelegt ist und damit ein günstigerer BIOS-Chip genügt, steht diese Option nicht mehr zur Verfügung, da das BIOS auf jeden Fall ins RAM entpackt werden muss. Hersteller wie Award verwendeten zum Packen von ihrem BIOS das LHA-Format.

Auf modernen Hauptplatinen ist das BIOS in einem wiederbeschreibbaren Speicher (genauer: EEPROM, meist Flash-Speicher) abgelegt. Daher kann es ohne Ausbau dieses Chips durch neuere Versionen ersetzt werden („Flashen“). Da ein Rechner ohne vollständiges BIOS jedoch nicht funktionsfähig ist, stellt dieser Vorgang immer ein gewisses Risiko dar. Wird er unterbrochen, beispielsweise durch einen Stromausfall, muss der Chip, auf dem das BIOS gespeichert ist, normalerweise ausgetauscht werden. Als Alternative wird im Internet von verschiedenen Institutionen auch das Neuprogrammieren des Chips angeboten. Selbst aufgelötete Flash-Speicher stellen für Fachpersonal nur ein geringfügiges Problem dar. Auf neuen Boards werden immer häufiger sogenannte serielle Flashspeicher verwendet, die es im Fehlerfall teilweise ermöglichen, per SPI-BUS auf dem Board neu programmiert zu werden.

Bootblock

Mit der Zeit entwickelten American Megatrends, Award Software, Phoenix und andere Hersteller „BootBlock“/Wiederherstellungs-BIOS-Bereiche, die bei einem Flash-Vorgang dann normalerweise nicht mehr überschrieben werden. Schlug der Flash-Vorgang fehl, startet das „BootBlock“/Wiederherstellungs-BIOS und ermöglicht es, von Diskette zu booten. Bei einigen BIOS-Varianten kann sogar eine spezielle Wiederherstellungs-CD/-Diskette erstellt werden, die auch bei einem defekten BIOS durch Setzen eines Jumpers automatisch das BIOS wiederherstellt. Dazu sind keinerlei Benutzereingaben und keine grafische Ausgabe nötig, da diese bei defektem BIOS meist ohnehin nicht mehr funktionieren.

Einige Hauptplatinen bieten ein sogenanntes DualBIOS an. Im Fehlerfall kann das zweite (noch intakte) BIOS den Startvorgang übernehmen und die Änderung rückgängig gemacht werden. Das kann beim Flashen des BIOS ein Rettungsanker sein, sollte die neu aufgespielte BIOS-Version nicht funktionieren. Des Weiteren können mit einem DualBIOS verschiedene BIOS-Einstellungen geladen werden.

Da das Aktualisieren eines Flash-BIOS heute schon unter einem laufenden Windows möglich ist, eröffnen sich damit neue Einfallswege für Viren-Befall. Wenn auf diesem Wege beispielsweise ein Rootkit installiert würde, könnte es sich noch einmal wesentlich effizienter gegen Entdeckung und Löschung abschotten. Außerdem kann ein Absturz des Betriebssystems während des Flashens den PC eventuell unbootbar machen (siehe oben).

BIOS-Hersteller

Eine Auswahl von Herstellern von BIOSen für IBM-kompatible PCs:

• American Megatrends
• Phoenix/Award – Award und Phoenix haben 1998 fusioniert. Award wird von dem Unternehmen als Desktop-Produkt geliefert. Die Phoenix-Produktreihe wird hingegen bei Servern und Laptops eingesetzt.
• MR BIOS
• ATI Technologies
• IBM
• Insyde

Vergleichbare Konzepte

BIOS bei CP/M-Computern

Das Konzept und der Begriff „BIOS“ (als Basic Input/Output System) gehen auf Gary Kildall, den Erfinder und Entwickler des Betriebssystems CP/M (Control Program for Microcomputers) zurück und wurde von ihm bereits 1975 in dieser Bedeutung benutzt. CP/M hatte vor der Einführung des IBM PCs einen vergleichbaren Marktdurchdringungsgrad unter damaligen Kleinrechnern, wie später PC DOS bzw. MS-DOS auf IBM-kompatiblen PCs. Da jedoch vor der Etablierung IBM-kompatibler PCs kein über die Herstellergrenzen hinaus geltender Hardware-Standard existierte und jeder Hersteller von Kleinrechnern dabei völlig verschiedene Konzepte verfolgte, war es notwendig, die hardwarespezifischen Teile des Betriebssystems für jedes System speziell anzupassen.

Handelte es sich anfangs noch um eine gedankliche Untergliederung, so wurden die hardwarespezifischen Teile während der Entwicklung von CP/M 1.3 und 1.4 (1977) auch in der Architektur des Systems von den hardwareunabhängigen Teilen isoliert. Anregungen für eine Entwicklung in diese Richtung gehen auch auf Glenn Ewing, der das CP/M-BIOS für IMSAI an den IMSAI 8080 anpasste, zurück. Digital Researchs CP/M bestand ab Release 1.4 aus zwei übereinanderliegenden Schichten, dem hardwarespezifischen BIOS und dem darauf aufbauenden, aber vollständig hardwareunabhängigen BDOS (Basic Disk Operating System). Die Anwendungen nutzten Systemaufrufe, die ihnen das BDOS zur Verfügung stellte, und zur Durchführung der verschiedenen Aufgaben rief das BDOS nach unten die hardwarespezifischen Routinen im BIOS auf, das die Hardwareansteuerung übernahm. Auf diese Weise blieben die Anwendungen über die Systemgrenzen hinweg portabel. Um CP/M für ein neues Rechnersystem anzubieten, konnte der jeweilige Hersteller einen Template-Quelltext des BIOS von Digital Research lizenzieren und nach eigenen Vorstellungen anpassen. Das BDOS wurde in der Regel nur als Objektdatei ausgeliefert und passend dazugelinkt. Im ROM selbst befand sich meist nur ein äußerst rudimentärer sog. Monitor und Bootloader, über den das erzeugte CP/M-Image von einem Medium wie einer Diskette oder Festplatte in den Speicher geladen und gestartet werden konnte. Auf diese Weise wurde CP/M auf mehr als dreitausend verschiedene Systeme angepasst und in den jeweils passenden Adaptionen von den Hardware-Herstellern angeboten. Einige CP/M-Abkömmlinge wie MP/M (Multi-tasking Program for Microcomputers), Concurrent CP/M 2.0-3.1 (CCP/M), Concurrent DOS 3.2-6.2 (CDOS), DOS Plus 1.2-2.1, FlexOS, Multiuser DOS 5.0-7.xx (MDOS), System Manager 7 und REAL/32 7.xx enthalten auch ein XIOS (Extended Input Output System).

BIOS bei MS-DOS-kompatiblen Rechnern

Das von Microsoft und IBM gemeinsam entwickelte Betriebssystem MS-DOS bzw. PC DOS lehnte sich ursprünglich sehr stark an das Vorbild CP/M an, deshalb findet sich auch hier die Aufteilung in einen hardwarespezifischen Teil, das sog. DOS-BIOS, und in den hardwareunabhängigen DOS-Kernel. Anders als bei CP/M lagen die beiden Teile jedoch in getrennten Dateien vor, die bei MS-DOS IO.SYS und MSDOS.SYS hießen, bei PC DOS hingegen IBMBIO.COM und IBMDOS.COM. Die MS-DOS-Version mit einem an IBM PCs angepassten DOS-BIOS hieß PC DOS, andere MS-DOS-OEM-Versionen lagen jedoch – ganz ähnlich wie CP/M – auch für Dutzende nicht IBM-kompatible x86-Systeme vor, bei denen das DOS-BIOS erst an die jeweilige Zielplattform angepasst werden musste.

Auch bei der PC-DOS-kompatiblen Single-User-Betriebssystemlinie DR DOS, die Anfang 1988 von Digital Researchs CP/M-Abkömmling Concurrent DOS 6.0 abgespalten wurde, indem das System seiner Multitasking-Fähigkeiten beraubt und das XIOS durch ein IBM-kompatibles DOS-BIOS ersetzt wurde, findet sich die gleiche Aufteilung in DOS-BIOS (DRBIOS.SYS bzw. IBMBIO.COM) und den bis heute BDOS genannten Kernel (DRBDOS.SYS bzw. IBMDOS.COM). Handelte es sich anfangs beim BDOS 6.0 von DR DOS 3.31 im Wesentlichen noch um einen CP/M-ähnlichen Kernel mit darübergestülptem DOS-Emulator PCMODE, wurde die interne Funktionsweise im Laufe der Zeit zunehmend – und endgültig ab BDOS 7.0 – auch intern an DOS-Standards angepasst. Das gilt auch für PalmDOS 1, Novell DOS 7, Caldera OpenDOS 7.01 und DR-DOS 7.02+.

Das DOS-BIOS von IBM-kompatiblen DOS-Ausgaben griff ausschließlich über das im ROM des Rechners eingebaute ROM-BIOS bzw. System-BIOS auf die Hardware zu. Dadurch konnten kleinere Unterschiede in der Hardware schon auf der Ebene des System-BIOSes gekapselt werden, so dass in solchen Fällen keine Änderung am DOS-BIOS mehr notwendig war. Mit der Verbreitung von Anwendungen, die am Betriebssystem vorbei direkt auf die Hardware zugriffen (und in der Folge mit der von IBM-kompatiblen Clones), wurden Anpassungen am DOS-BIOS im Laufe der Jahre zunehmend seltener notwendig, so dass auch MS-DOS später nur noch in einer generischen Version angeboten wurde, die einige Sonderfälle behandelte und so auf den meisten IBM-kompatiblen Rechnern lief.

Das ROM-BIOS (und ggf. im ROM vorliegende Teile des Betriebssystems) wurde in Digital-Research-Terminologie manchmal auch als ROS (Resident Operating System) bezeichnet.

XBIOS/TOS beim Atari ST

Beim Atari ST war das gesamte Betriebssystem TOS, einschließlich der ursprünglich von Digital Research entwickelten grafischen Benutzeroberfläche GEM, im ROM untergebracht und quasi direkt nach dem Einschalten betriebsbereit. Als BIOS wurde die unterste Schicht des Betriebssystems bezeichnet, für den Programmierer erkennbar als eine Sammlung speicherresidenter Funktionen. Darüberliegende Schichten (ebenfalls erkennbar als solche Sammlungen) waren:

• Das GEMDOS (GEM Disk Operating System)
• Das VDI (Virtual Device Interface)
• Das AES (Application Environment Services)

Das XBIOS (Extended Basic Input/Output System) war keine eigene Schicht, sondern lag parallel zum BIOS auf derselben Schicht, wobei einige Funktionen des XBIOS Hardware-näher angesiedelt waren.

Kickstart beim Commodore Amiga

Die Amiga-Rechner von Commodore benötigen als Firmware das sogenannte Kickstart. Es erfüllt alle Funktionen eines BIOS und enthält darüber hinaus auch den Kernel (exec) des AmigaOS. Die ersten Modelle des Amiga 1000 müssen nach dem Einschalten („Kaltstart“) noch per Bootstrap-Diskette mit den Kickstart-Versionen 1.0 bis 1.3 gestartet werden. Das Kickstart wird dabei im WOM, einem besonderen Bereich des RAM, abgelegt und gegen Überschreiben gesichert. Nach einem Reset (Warmstart) bleibt dieses im Speicher erhalten und braucht nicht neu geladen zu werden. Dieser Umstand hat den Vorteil, dass sehr schnell und unkompliziert auf eine neuere Version aktualisiert werden kann. Alle späteren Modelle, wie der Amiga 500 oder der Amiga 2000, verfügen über ein ROM, so dass die Version nur durch den Austausch des Bausteins geändert werden kann. Durch die Verwendung eines „Kickstart Switchers“ kann jedoch vor dem Einschalten zwischen zwei ROMs mit unterschiedlichen Kickstartversionen per Schalter gewechselt werden. Das wurde besonders seit Einführung von Kickstart 2.0 relevant, das Kompatibilitätsprobleme mit älteren Programmen, besonders Spielen, hat. Besitzer des „Amiga 500+“, der hauptsächlich für Computerspiele im Heimbereich ausgelegt ist und standardmäßig Kickstart 2.0 verwendet, sind für ältere Spiele auf einen solchen Kickstartswitcher angewiesen.

Open Firmware

Ursprünglich für Nicht-x86-Rechner (hauptsächlich SPARC und PowerPC) wurde von mehreren Herstellern (u. a. Sun) der plattformunabhängige Open-Firmware-Ansatz (IEEE-1275) auf Forth-Basis definiert. Dieser kommt nicht nur bei Suns Sparc-Rechnern, sondern auch bei PowerPC-basierten Rechnern von IBM und Apple sowie bei CHRP-Rechnern anderer Hersteller wie Genesi (mit dem Pegasos) zum Einsatz. 2006 wurden fast alle Open-Firmware-Implementationen unter einer BSD-Lizenz veröffentlicht. Im Laptop OLPC XO-1 (Produktion ab 2007) findet sich Open Firmware erstmals auch auf der x86-Architektur. Mit OpenBIOS steht zudem eine freie Implementierung für x86-Rechner zur Verfügung, die mangels Betriebssystemunterstützung hauptsächlich zur Forth-Programmierung eingesetzt werden kann.

Extensible Firmware Interface

Ende der 1990er wollte Intel zuerst im Server-Bereich von x86 auf die Itanium-Architektur wechseln. In dieser löste Intel das damals rund 20 Jahre alte BIOS Jahre durch die Eigenentwicklung Extensible Firmware Interface, kurz EFI, ab. Gleichzeitig wurde die x86-Architektur in IA-32 umbenannt, was für „Intel Architecture 32-Bit“ stand, die Itanium-Architektur wurde von Intel hingegen als „Intel Architecture 64-Bit“ beworben. Doch der Wechsel zu Itanium misslang, unter anderem auch deshalb, weil AMD die AMD64 genannte Erweiterung für den x86-Befehlssatz entwickelte und damit die „Intel Architecture 32-Bit“ zu einem 64-Bit-System machte. So wurden bis zur Mitte der 2000er Jahre viele 64-Bit-x86-Server ausgeliefert und Intel war gezwungen die eigenen IA-32-Prozessoren ebenfalls 64-Bit-fähig zu machen – was eine direkte Konkurrenz zur Itanium-Architektur aus dem eigenen Haus bedeutete.

Die ersten 64-Bit-x86-Systeme nutzten weiter das Mitte der 2000er Jahre über 25 Jahre alte BIOS. Intel veröffentlichte daher 2004 EFI 1.1 für x86 bzw. IA-32 unter dem Namen Tiano. 2005 stellte Intel die Firmware unter die Kontrolle eines Gremiums, in dem seither führende Unternehmen aus der IT-Branche mitarbeiten und für die Weiterentwicklung von EFI zuständig sind. Die Firmware wurde dabei in Unified Extensible Firmware Interface, kurz UEFI, umbenannt.

2006 war Apple der erste und einzige Hersteller von Desktop-PCs, der EFI einsetzte: nach dem Verlassen der PowerPC-Architektur hin zu IA-32 stellte Apple von der auf dem PowerPC genutzten Open Firmware zu EFI 1.1 von Intel um, jedoch mit eigenen Mac-spezifischen Erweiterungen. Mit dem in EFI enthaltenen Compatibility Support Module, kurz CSM, kann damit auf einem Intel-Mac auch ein PC-Betriebssystem, welches ein BIOS voraussetzt, gestartet werden, was Apple über die (spätere) Software Boot Camp offiziell für Windows ermöglicht.

Auf x86-PCs anderer Hersteller wurde UEFI nach und nach eingeführt, sodass auch PCs mit AMD-Prozessoren UEFI als Firmware boten. Allerdings muss auch das Betriebssystem UEFI unterstützen oder das in vielen UEFI-Implementierungen integrierte Compatibility Support Module, CSM, nutzen.

Linux war das erste PC-Betriebssystem, das von EFI bzw. UEFI starten konnte. Microsoft wollte UEFI-Unterstützung für sein Desktop-Betriebssystem mit Windows Vista einführen, doch erst mit dem Service Pack 1 wurde UEFI-Unterstützung auf der x64-Variante von Windows Vista nachgereicht. Seit Windows 8 hat sich UEFI auf dem Desktop endgültig durchgesetzt, setzt aber immer ein x64-Betriebssystem voraus. 32-Bit-Windows-Versionen benötigen weiterhin ein BIOS oder CSM.

Windows benötigt UEFI in Version 2.0 und höher. EFI 1.1, wie es viele Apple-Computer integrieren, ist für den nativen UEFI-Betrieb von Windows nicht geeignet. Die Mac-EFI-Implementierung von Apple enthält einige Abweichungen von der UEFI-Spezifikation.

Auf 64-Bit-PC-Systemen, die auch als x64 bezeichnet werden, hat sich UEFI seit Mitte der 2010er Jahre als Standard etabliert.

Simple Firmware Interface

Mit dem Engagement von Intel in der Smartphone- und MID-Technik wurde das Simple Firmware Interface (SFI) entwickelt. Es ist frei von alten und lizenzkostenpflichtigen PC-BIOS-Patenten. Es benötigt deshalb aber auch neuere, speziell für SFI angepasste Betriebssysteme. SFI findet auf Intels Moorestown-Plattform Anwendung.

Kritik

Eine Firmware-Schnittstelle wie BIOS und UEFI ist sehr tief im System verankert und daher eine potenziell sicherheitskritische Komponente.

Punkte, die zu einer kritischen Betrachtung eines herstellerabhängigen BIOS führen:

• Proprietärer Code: Absichtliche oder unabsichtliche Sicherheitslücken entziehen sich der öffentlichen Kontrolle (Möglichkeit der Ausspähung, Manipulation und Industriespionage) – die NSA erarbeitete 2010 dazu eine Durchführbarkeitsstudie.
• Die Einstufung der Vertrauenswürdigkeit von Software unterliegt beim BIOS-Nachfolger UEFI allein der Firma Microsoft.
• Es gibt nur zwei BIOS-Produzenten – beide residieren in den USA und unterliegen deren Bestimmungen.
• UEFI erfüllt nicht die Anforderungen zur Computersicherheit der deutschen Bundesregierung.
• Mögliche feste Implementation von Nutzungseinschränkungen, etwa Digital Rights Management.

Freie BIOS-Alternativen

Die verschiedenen BIOS-Implementierungen der PCs sind im Regelfall proprietäre Software, was große Unsicherheiten birgt: da der Quellcode nicht bekanntgegeben wird, werden Sicherheitslücken teilweise nicht rechtzeitig erkannt. Auch kann ein proprietäres BIOS den Benutzer an Tätigkeiten hindern, die von der Hardware des Gerätes her kein Problem darstellen würden: so erlaubt beispielsweise das BIOS der Xbox es nicht, andere Software als die von Microsoft zugelassene zu starten.

Es ist möglich, den Flash-ROM-Baustein (früher: EPROM), auf dem das BIOS abgelegt ist, zu ersetzen oder zu überschreiben, um so beispielsweise den Linux-Kernel direkt aus dem Flash heraus zu starten, ohne BIOS. Die Vorgehensweise ist jedoch von der jeweiligen Hauptplatine abhängig und wird überwiegend in Industriecomputern eingesetzt.

Projekte mit diesem Ziel sind etwa coreboot (ehemals LinuxBIOS) oder OpenBIOS – letzteres ist allerdings eine Open-Firmware-Implementation.

Normen, Standards, Richtlinien

Standard über das Zusammenwirken von BIOS-Systemstart, Initial Program Load und BIOS-Funktionsergänzungen

Das Zusammenwirken von BIOS-Systemstart, Initial Program Load und BIOS-Funktionsergänzungen wird durch die sogenannte „BIOS Boot Specification“ vom 11. Januar 1996, einem von einem Firmenkonsortium ausgearbeiteten Standard, geregelt.

Dieser Standard fixiert insbesondere, auf welche Art und Weise Initial-Program-Load- (Bootstrapload-) Komponenten, die (den BIOS-Systemstart fortsetzend) das Hochlaufen der jeweiligen Betriebssysteme herbeiführen, vom BIOS identifiziert werden und wie unter Vorgabe der durch den Computerbenutzer festgelegten Priorität (entsprechend der sogenannten Bootsequenz) versucht wird, eine oder mehrere der jeweiligen Komponenten zur Ausführung zu bringen.

Direkt oder indirekt legt dieser Standard auch fest, wie etwa ein Initial Program Loader (Bootstraploader) ein auf das BIOS abgestimmtes Verhalten zustandezubringen hat und wie das BIOS das jeweils gerade verwendete Bootmedium (Festplatte, optische Laufwerk-Disk, USB-Stick, PCMCIA-Netzwerkkarte, Ethernetkarte oder dergleichen) für den Loader handhabt.

Für die Bereitstellung von Bootmechanismen spielt die Programmierschnittstelle zwischen BIOS-Verwaltung und Bootverwaltung, das sogenannte „BIOS Boot Specification API“, eine Rolle, wobei die Implementierung dieser Mechanismen in der Regel sowohl hardware- als auch softwaremäßig erfolgt (sofern man jeweils ganze Bootmechanismen ins Auge fasst). Hardwaremäßig kann eine solche Implementierung durch BIOS-Funktionsergänzungen bewerkstelligt werden, etwa, wenn das Motherboard-BIOS durch ergänzende Add-In-Firmware-BIOSe von Netzwerk-, SCSI- oder RAID-Adaptern erweitert und/oder partiell ausgetauscht wird. Softwaremäßig kann eine solche Implementierung durch Programmierung entsprechender Routinen bzw. Treiber geschehen, sofern diese speicherresident untergebracht werden können; unter gewissen Voraussetzungen können auch Initial Program Loader bzw. Bootstraploader bei der Bereitstellung von unkonventionellen Bootmechanismen besondere Funktionen einnehmen bzw. eine besondere Rolle spielen. Beim Rechnerhochlauf via Netzwerkkarte sind die meisten Bootmechanismen weit komplizierter als beim klassischen (einfachen) Initial Program Load. In diese Kategorie gehört beispielsweise der Fall, dass der Rechnerhochlauf von einem außenstehenden Rechner über das Netzwerk (etwa via Fast-Ethernetadapter) angestoßen wird (siehe auch Wake on LAN). Das Motherboard-BIOS, das im Regelfall keinen Treibercode für das Booten über eine bestimmte Netzwerkkarte besitzt, wird durch Add-In-Firmware auf der Netzwerkkarte unter Beachtung der Vorgaben des BIOS Boot Specification APIs ergänzt, sodass eine speicherresidente Routine im Dienste der Netzwerkkarte den Bootmechanismus umlenken und die Netzwerkkarte als auswählbares Bootmedium am System anmelden kann. Nach erfolgter Auswahl der Netzwerkkarten-Bootoption im BIOS geht dann der BIOS-Systemstart in eine Netzwerkkommunikation über, in der Auskünfte über Bootserveradressen eingeholt werden und Abfragevorgänge stattfinden. Das beinhaltet eine Art „Bereitschaftszustand“ des Rechners, der durch Auslösung übers Netzwerk jederzeit hochfahrbar wird. Auf die richtige Meldung hin wird der Bootstraploader in den RAM-Speicher heruntergeladen und ausgeführt.

Siehe auch

• Liste der BIOS-Signaltöne

Literatur

• Klaus Dembowski: BIOS und Troubleshooting. kompakt, komplett, kompetent. Markt und Technik, München 2004, ISBN 3-8272-6547-9. 

Weblinks

Commons: BIOS – Sammlung von Bildern, Videos und Audiodateien

• Flashrom, universelles open-source Flash-Tool (DOS, Linux, Mac OS X, Open-, Net-, FreeBSD und andere Unix-Derivate)
• Uniflash, universelles Flash-Tool für DOS (Memento vom 9. Februar 2008 im Internet Archive)
• Uniflash, universelles Flash-Tool für DOS (derzeitige Rainbow Software Seite von Uniflash 1.40)
• BIOS-Kompendium (deutsch)