BIOS

Dieser Artikel behandelt die Computer-Firmware. Zu weiteren Bedeutungen siehe Bios.

Unter dem Begriff BIOS (IPA: [ˈbaɪɔs], Aussprache^ⓘ/?, von englisch basic input/output system) wird im Allgemeinen die Firmware eines Personal Computer verstanden („PC-Firmware“), die beim Kaltstart des Computers durch Bootstrapping das Starten weiterer Software, wie des Betriebssystems, ermöglicht. Die Übereinstimmung dieses Akronyms mit dem altgriechischen Wort βίος (nach dem lateinischen Alphabet bios, zu deutsch Leben) ist eine Anspielung darauf, dass einem Computer mit dieser so benannten Software quasi Leben eingehaucht wird.

Ursprünglich wurde die System-Firmware oder Systemfirmware eines Computersystems auf der Hauptplatine (englisch Mainboard) auf einem ROM-Chip (Boot-ROM) gespeichert und auch als System-ROM oder ROM-BIOS bezeichnet.

Der Begriff „BIOS“ hat sich aufgrund des großen Erfolgs von IBM-PC-kompatiblen Computern, die als System-Firmware das Konzept eines BIOS aus dem Betriebssystem CP/M als ROM-BIOS übernahmen, auch auf anderen Computersystemen verbreitet (etwa als AlphaBIOS oder UEFI-BIOS).

Aufgabe

Die System-Firmware löst zwei Probleme, die beim Start eines Computersystems 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. Meist sind die Firmware-Treiber zu langsam und/oder haben zu viele Einschränkungen. Beim PC-BIOS (das bis rund 2010 in IBM-kompatiblen PCs verwendet wurde) sind eigene Treiber die einzige Möglichkeit, weil die Real-Mode-BIOS-Funktionen im Protected und Long Mode nicht verfügbar sind – in einem von diesem laufen aber moderne PC-Betriebssysteme, unter anderem um einen größeren Arbeitsspeicher verwalten zu können und um Multitasking einfach zu organisieren.

Begriff

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 der BDOS-Kernel zur Verfügung stellte, und zur Durchführung der verschiedenen Aufgaben rief BDOS nach unten die hardwarespezifischen Routinen im CP/M-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 Vorlage-Quelltext des BIOS von Digital Research lizenzieren und nach eigenen Vorstellungen anpassen. 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).

System-Firmware verschiedener Plattformen

Als ein Merkmal einer Plattform kann auch die Kompatibilität zu einem System-BIOS gelten, wenn diese für den Betrieb von Software wesentlich ist. Während diese für Betriebssysteme meist unverzichtbar ist, stellt das BIOS für Programme und Applikationen oft eine untergeordnete Rolle dar, da sich diese wiederum auf das Betriebssystem selbst als Plattform abstützen. So verwendeten auf älteren Computern wie dem Apple II oder DOS-PCs Computerprogramme noch vielfach Funktionen der Firmware auch direkt, auf modernen macOS- und Windows-Systemen hingegen ist das „BIOS“ für Anwendungsprogramme kein wesentliches Plattform-Element mehr. Für Applikationen auf dem Mac ist es nicht wesentlich, ob diese auf einem Computer mit Open Firmware oder UEFI (oder sogar dem BIOS) laufen. Ebenso ist es für Windows-Programme unerheblich, ob diese auf PCs mit BIOS (IBM-PC-kompatiblen Computern) oder auf Computern mit UEFI laufen.

Apple II: System Monitor

Auf dem Apple II ist der System Monitor im ROM gespeichert. Dieser stellt neben einem einfachen Texteditor und einem Kommandointerpreter alle wesentlichen Grundfunktionen zur Verfügung, wie das Lesen und Schreiben der Datasette. Der Apple II bot auch ein ROM-BASIC.

IBM PC: BIOS

→ Hauptartikel: BIOS (IBM PC)

Das BIOS ist beim IBM PC von 1981 der zentrale Bestandteil, der bei ähnlichen Systemen zuvor noch bei jedem Betriebssystem (damals verbreitet war zumeist CP/M) an jeden Computer angepasst in Software mitgeliefert werden musste (siehe DOS-BIOS). Das PC-BIOS wurde von IBM mit Funktionen ausgestattet, die den Zugriff auf die Hardware des PCs erlauben und somit dem Betriebssystem PC DOS die Notwendigkeit, spezielle entwickelte Gerätetreiber dafür bereitzustellen, ersparte. Es wurde auch zum Alleinstellungsmerkmal, denn der IBM PC, Model 5150, war im Grunde ein System „von der Stange“, das somit grundsätzlich Nachbauten ermöglichte. Nur das BIOS wurde von IBM urheberrechtlich geschützt – Hersteller von Klonen des IBM PC durften daher das BIOS nicht kopieren und wurden verklagt, wenn sie es doch taten.

→ Hauptartikel: IBM-PC-kompatibler Computer#BIOS

Als das BIOS schließlich per Reverse Engineering nachprogrammiert wurde, konnten die BIOS-Funktionen auch von den Nachbauern in deren nunmehr IBM-kompatible PCs integriert werden.

Durch den großen Erfolg des IBM PC und seiner Nachbauten war das BIOS, bzw. eine Version davon, im Großteil aller x86-Rechner in Verwendung. In der Mitte der 2000er Jahre wurde das BIOS zunehmend vom Extensible Firmware Interface, das von Intel entwickelt worden war, ersetzt. Dieses bot mit dem Compatibility Support Module eine BIOS-Emulation, sodass ein UEFI mit aktiviertem CSM auf ein Betriebssystem wie ein PC mit BIOS wirkte – vorhandene Betriebssysteme blieben somit mit derartigen Computern kompatibel, was zu jener Zeit neben dem nicht mehr weit verbreiteten PC-kompatiblen DOS vor allem Windows XP war, ein Windows-Betriebssystem der NT-Linie. Spätere Windows-Versionen unterstützten bereits EFI bzw. den ab 2006 als „Unified EFI“ (UEFI) weiterentwickelten BIOS-Nachfolger, ebenso wie die meisten anderen PC-Betriebssysteme (u. a. Linux, PC-BSD).

Bei den ersten IBM PCs war neben dem BIOS auch ein BASIC-Interpreter im ROM untergebracht (siehe BASICA). Auf speziellen Systemen war auch ein DOS im ROM untergebracht (ROM-DOS).

Das ROM-BIOS (und ggf. im ROM vorliegende Teile des Betriebssystems) wurde in Digital-Research-Terminologie (dem Entwickler von CP/M und später DR DOS) manchmal auch als „Resident Operating System“ (ROS) bezeichnet.

Atari ST: TOS (XBIOS, BIOS)

→ Hauptartikel: TOS (Betriebssystem)

Beim Atari ST ist 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. Die unterste Schicht von TOS wird mit XBIOS bezeichnet, für den Programmierer erkennbar als eine Sammlung speicherresidenter Funktionen. Sie werden über Trap #14 der 68000-Architektur aufgerufen. Darüber liegend sind Funktionen des BIOS, die über Trap #13 aufgerufen werden. Das XBIOS und das BIOS liegen zwar parallel auf derselben Schicht, einige Funktionen des XBIOS sind jedoch Hardware-näher angesiedelt.

Bestandteile von TOS, die sich im ROM befinden:

• XBIOS (Extended BIOS)
• BIOS (Basic Input Output System)
• GEMDOS (GEM Disk Operating System)

Die über dem BIOS liegenden Schichten, die ebenfalls als Sammlungen von Funktionen für Programme zur Verfügung stehen, sind:

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

Commodore Amiga: Kickstart

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 es 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 dieses 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

→ Hauptartikel: 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.

Alpha: ARC/AlphaBIOS und SRM

Auf DEC Alpha gibt es zwei verschiedene System-Firmware-Interfaces: ARC/AlphaBIOS und SRM. Neuere Versionen beinhalten die Option, zwischen beiden Interfaces umzuschalten.

• ARC bzw. AlphaBIOS

• SRM

→ Hauptartikel: System Reference Manual

(Unified) Extensible Firmware Interface (EFI, UEFI)

→ Hauptartikel: Unified Extensible Firmware Interface

Ende der 1990er wollte Intel zuerst im Server-Bereich von der x86- auf die Itanium-Architektur wechseln. In dieser löste Intel das damals rund 20 Jahre alte BIOS 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 steht, die Itanium-Architektur wurde von Intel hingegen als Intel Architecture 64-Bit („IA-64“) 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 x86-Architektur ebenfalls zu einem 64-Bit-System machte – „x64“ oder „x86-64“. 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 PC-BIOS voraussetzt, gestartet werden, was Apple über die (spätere) Software Boot Camp offiziell für Windows ermöglichte.

Auf x86-PCs anderer Hersteller wurde UEFI nach und nach eingeführt, so dass auch PCs mit AMD-Prozessoren UEFI als Firmware boten. Allerdings muss auch das Betriebssystem UEFI unterstützen. Da dies Ende der 2000er Jahre noch nicht durchwegs der Fall war, bot das in UEFI-Implementierungen integrierte Compatibility Support Module, CSM, eine BIOS-Kompatibilität, die erst rund 2020 aus UEFI entfernt wurde.

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 nachgereicht. Seit Windows 8, das auch 32-Bit-EFI-Implementierungen ab EFI 1.1 unterstützt, hat sich UEFI (ab rund 2010 fast ausschließlich als 64-Bit-UEFI) auf dem Desktop endgültig durchgesetzt, wobei Windows die gleiche Architektur wie die jeweilige UEFI-Implementierung erfordert: auf 32-Bit-EFI laufen nur 32-Bit-Windows-Versionen ab Windows 8, während auf dem PC-BIOS bzw. auf (U)EFI mit aktivem CSM („Legacy BIOS Mode“), ein x64-Prozessor vorausgesetzt, sowohl die 32- („x86“) als auch die 64-Bit-Version („x64“) gestartet werden kann, allerdings steht im BIOS-Modus die GUID-Partitionstabelle (GPT) nicht zur Verfügung, sodass die Installationsfestplatte von Windows aufgrund des MBR-Partitionsschema auf 2,2 TB beschränkt bleibt. Unter Linux kann sowohl BIOS/UEFI als auch MBR/GPT beliebig kombiniert werden, sodass ein 32-Bit- oder 64-Bit-Linux auf einem 32-Bit- oder 64-Bit-(U)EFI mit MBR genauso startet wie ein 32-/64-Bit-Linux auf einem BIOS-Computer mit GPT.

Windows 7 benötigt UEFI in Version 2.0 und höher. EFI 1.1, wie in vielen älteren Apple-Computern bis ca. 2013 integriert, ist für den nativen UEFI-Betrieb von Windows oft nicht geeignet, denn obwohl Windows Vista SP1 und 8/8.1 grundsätzlich auch EFI 1.1 unterstützen, sind teils die Grafiktreiber auf ein Video-BIOS angewiesen und funktionieren im nativen UEFI-Modus nicht. Zusätzlich enthält die EFI-Implementierung von Apple auf dem Mac einige Abweichungen von der UEFI-Spezifikation, während das CSM voll PC-kompatibel ist. Somit lassen sich nur einige spätere Macs nativ mit Windows im UEFI-Modus nutzen, während auf allen (älteren) Macs nur bestimmte Windows-PE-Versionen (ein Windows-Live-System) im nativen UEFI-Modus fehlerfrei starten.

Auf 64-Bit-PC-Systemen, die auch als x64 bezeichnet werden, hat sich UEFI seit Mitte der 2010er Jahre als Standard etabliert und damit das „Legacy-BIOS“ obsolet gemacht. Seit rund 2020 ist in neuen Computersystemen das BIOS-Kompatibilitätsmodul (kurz CSM) standardmäßig nicht mit im UEFI enthalten. Auf Apple Silicon (Arm-basierte Macs), die die Intel-Macs ab 2020 sukzessive ersetzten, hat sich Apple auch von UEFI verabschiedet.

Common Firmware Environment (CFE)

Das Common Firmware Environment (CFE) ist eine ab ca. 2000 von Broadcom für die eigene SiByte-Prozessorfamilie entwickelte einfache Firmware, die von Erstausrüstern („OEMs“) für deren Produkte angepasst werden kann. Obwohl CFE ursprünglich nur für die MIPS64-Plattform gedacht war, wurde es auch auf andere Architekturen portiert, etwa die PowerPC-Architektur des AmigaOne X1000.

Simple Firmware Interface (SFI)

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. Deshalb benötigt es aber auch neuere, speziell für SFI angepasste Betriebssysteme. SFI findet auf Intels Moorestown-Plattform Anwendung.

Kritik an proprietärer Firmware

Firmware-Schnittstellen wie das BIOS oder der Nachfolger UEFI sind sehr tief im System verankert und daher potenziell sicherheitskritische Komponenten.

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 Unsicherheiten bergen kann: 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), Libreboot (ein Coreboot-Fork ohne BLOBs) oder OpenBIOS – letzteres ist allerdings eine Open-Firmware-Implementation.

Einzelnachweise

1. Thorsten Leemhuis: Was die Begriffe Firmware, BIOS, UEFI alles meinen können. In: Heise online. 8. Mai 2019. Abgerufen am 30. Oktober 2022.; Zitat: „Anwender kommen mit den verschiedenen Firmwares in PCs selten in Kontakt. Nur eine haben sie oft vor der Nase: Die Firmware des Mainboards, die als BIOS gilt. Ausgeschrieben steht das für ‚Basic Input/Output System‘, was man mit ‚Grundlegendes Ein-/Ausgabe-System‘ übersetzen kann.“.
2. BIOS Definition, the Linux Information Project, online abgerufen am 20. Dezember 2018.
3. Thorsten Leemhuis: Aufhelfen – Linux-Boot-Probleme erkennen und lösen. In: c’t. Band 2012, Nr. 6. Verlag Heinz Heise, 27. Dezember 2006, S. 195 f., Die wichtigsten Abschnitte bei Start eines modernen Linux-Systems (Artikel-Archiv c’t 6/2012, Seite 195, kostenpflichtig [PDF; 626 kB; abgerufen am 25. November 2022]): „System-Firmware (BIOS/UEFI); Grundlegende Systemeinrichtung“ 
4. Jean-Ian Boutin (ESET), McAfee, Ryan Becwar: Pre-OS Boot: System Firmware. In: ATT&CK – knowledge base of adversary tactics and techniques. MITRE, 19. Mai 2020, abgerufen am 25. November 2022 (englisch): „The BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) or Extensible Firmware Interface (EFI) are examples of system firmware that operate as the software interface between the operating system and hardware of a computer.“ 
5. Isabelle Bauer: Windows-11-Test-Tools: So checken Sie die Kompatibilität. In: Heise online. 13. Oktober 2021. Abgerufen am 25. November 2022.; Zitat: „Systemanforderungen für Windows 11 … System-Firmware: UEFI, Secure-Boot-fähig“.
6. Subrata Banik: System Firmware: An Essential Guide to Open Source and Embedded Solutions. 1. Auflage. Apress, 2022, ISBN 978-1-4842-7938-0 (englisch). 
7. Mark Ciampa: CompTIA CySA+ Guide to Cybersecurity Analyst (CS0-002). 2. Auflage. Cengage Learning, 2022, ISBN 978-0-357-67811-4, Part 2, Module 6, S. 148, Hardware Best Practices (englisch, eingeschränkte Vorschau in der Google-Buchsuche): “Originally, BIOS firmware was stored in a ROM chip on the motherboard, supplemented by a CMOS … chip that stored any changes to the BIOS.” 
8. Jeffrey Krantz, Ann Mizell, Robert Williams: OS/2 für Anwender und Systementwickler. 1. Auflage. Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, 1989, ISBN 3-663-01987-X, 1. Die OS/2-Perspektive, S. 24, Der Personal Computer (eingeschränkte Vorschau in der Google-Buchsuche – amerikanisches Englisch: OS/2 – Features, Functions and Applications. Übersetzt von Almut Kleine, Johanna Heiss): „Die CPU hat keinerlei Einfluß auf das System-ROM, d. h. sie kann keine Veränderungen im ROM vornehmen. Ihr einziger Kontakt mit dem ROM besteht darin, daß sie das ROM lesen kann. Im neuen Personal System/2 sind im ROM BIOS-Code und Systemdaten untergebracht.“ 
9. Gerhard Franken: DOS ge-packt. 1. Auflage. mitp, 2003, ISBN 3-8266-1313-9, 1. Aufgabe und Funktion des Betriebssystems, S. 21, 1.1 Firmware und ROM-BIOS (eingeschränkte Vorschau in der Google-Buchsuche). 
10. Gaby Chaudry: Digital Research Source Code. In: The Unofficial CP/M Web site. Gaby Chaudry, 7. Februar 2020, abgerufen am 31. Oktober 2022 (englisch, der CP/M-1.x-Quelltext findet sich unter ‚OPERATING SYSTEMS‘ – ‚CP/M 1.x, and before...‘ – ‚EARLY CP/M SOURCE‘…). 
11. (Memento des Originals vom 29. Dezember 2012 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.imsai.net
12. Philippe Darche: Microprocessor 5: Software and Hardware Aspects of Development, Debugging and Testing – The Microcomputer. John Wiley & Sons, 2020, ISBN 978-1-78630-651-7, 3. Changes in the Organization of the Earliest Microcomputers; 3.5 Evolution of microcomputer firmware, S. 104, 3.5.2 Apple II (englisch, eingeschränkte Vorschau in der Google-Buchsuche): “Two programs, a resident system monitor and the BASIC interpreter, were installed on the motherboard. They were written by Steve Wozniak.” 
13. tos.hyp: Das XBIOS. In: Die Anleitung zum TOS. FreeMiNT Project, 1. Januar 2023, abgerufen am 4. Januar 2023: „Diese Funktionen ermöglichen den geordneten Zugriff auf die verschiedenen Spezial-Chips im Atari. Sie werden über den 680X0-Trap #14 aufgerufen und sollten nur verwendet werden, wenn keine Routinen einer höheren Ebene (GEMDOS, BIOS) zur Verfügung stehen, die statt dessen benutzt werden könnten.“ 
14. tos.hyp: Das BIOS. In: Die Anleitung zum TOS. FreeMiNT Project, 1. Januar 2023, abgerufen am 4. Januar 2023: „Die BIOS-Funktionen stellen die unterste Schnittstelle des Betriebssystems zur Hardware des Atari dar, und werden über den 680X0-Trap#13 aufgerufen.“ 
15. Werner Zimmermann: Entwicklung eines Zugriffssystems zu textlosen Sinnbildern nach DIN 30600; Diplomarbeit an der Technischen Universität Darmstadt. Diplomarbeiten Argentur (Diplom.de), 1995, ISBN 3-8324-0486-4, 4.2.2 Betriebssystem, S. 22 (eingeschränkte Vorschau in der Google-Buchsuche). 
16. Livewings: MacBook Air 2013 is the first Mac that supports EFI booting on Windows natively. (Internetforum) In: MacRumors. 21. Juni 2013, abgerufen am 1. Januar 2023 (englisch, Ab ca. 2013 sind Intel-Mac großteils kompatibel zu UEFI 2.0.). 
17. Loner T: Windows 10 UEFI Driver Compatibility. (Internetforum) In: Apple Community Discussions. Apple, 3. August 2015, abgerufen am 1. Januar 2023 (englisch): „Macs prior to Late 2013 have used EFI 1.1.“ 
18. (Memento vom 31. Januar 2011 im Internet Archive)
19. Ralf Hutter, Manfred Kloiber, Peter Welchering: "Coreboot" schützt vor Überwachung. Deutschlandfunk – Computer und Kommunikation, 18. April 2015, abgerufen am 25. April 2015.