Der UEFI‑Bootprozess - Schritt für Schritt vom Power‑On zum Kernel

21.02.2026 · 4 Min. Lesezeit

Der UEFI‑Bootprozess verfolgt dasselbe Ziel wie der klassische BIOS‑Boot: Er soll ein Betriebssystem starten. Doch der Weg dorthin ist grundlegend anders. Während das BIOS gerade genug tut, um fremden Code zu laden, versteht sich UEFI als strukturierte, kontrollierte Startplattform. UEFI ersetzt den linearen, historisch gewachsenen Ablauf durch einen klar gegliederten Prozess mit definierten Phasen, Verantwortlichkeiten und Sicherheitsgrenzen. Genau diese Struktur schauen wir uns nun Schritt für Schritt an.

1. Einschalten und CPU‑Reset

Wie beim BIOS beginnt alles mit einem elektrischen Vorgang. Strom stabilisiert sich, die CPU wird aus dem Reset gelöst und startet an einer festgelegten Adresse. Der entscheidende Unterschied liegt nicht im Start, sondern im Ziel dieser Adresse. Statt eines monolithischen BIOS‑Blocks landet die CPU bei einem UEFI‑Firmware‑Einstiegspunkt, der bereits für Modularität und Phasensteuerung ausgelegt ist. Der Rechner betritt damit nicht einfach einen Codepfad, sondern einen definierten Initialisierungsprozess.

2. SEC‑Phase - Establishing Trust

Die erste UEFI‑Phase heißt SEC (Security). Sie hat eine einzige, extrem wichtige Aufgabe: einen vertrauenswürdigen Ausführungsrahmen zu etablieren. In dieser Phase:

• wird minimaler Arbeitsspeicher aktiviert
• wird die Integrität der nächsten Firmware‑Komponenten sichergestellt
• werden grundlegende Sicherheitsannahmen gesetzt

Diese Phase ist bewusst klein gehalten. Sie enthält so wenig Code wie möglich - genau aus dem Grund, dass sie implizit vertraut werden muss. UEFI denkt Sicherheit von der ersten Instruktion an, nicht als spätere Erweiterung.

3. PEI‑Phase - Pre‑EFI Initialization

In der PEI‑Phase übernimmt UEFI erstmals aktiv die Plattforminitialisierung. Anders als beim BIOS geschieht dies nicht implizit, sondern strukturiert. Hier passiert unter anderem:

• vollständige RAM‑Initialisierung
• Aufbau elementarer Plattforminformationen
• Erkennen grundlegender Hardwareeigenschaften
• Bereitstellung standardisierter Hand‑off‑Informationen

Wichtig ist:
Die PEI‑Phase produziert Wissen, nicht nur Zustand. Sie sammelt Informationen über das System und stellt sie der nächsten Phase strukturiert zur Verfügung.

4. DXE‑Phase - Driver Execution Environment

Die DXE‑Phase ist der Kern von UEFI und der größte konzeptionelle Bruch zum BIOS. Hier wird UEFI zu einer echten Firmware‑Plattform. In dieser Phase:

• werden UEFI‑Treiber geladen
• wird Hardware umfassend initialisiert
• stehen bereits Dateisysteme zur Verfügung
• existieren standardisierte Firmware‑Services

UEFI kann jetzt Dinge, die BIOS nie konnte:

• von komplexen Massenspeichern lesen
• Netzwerkschnittstellen initialisieren
• Geräte modular nachladen

Das System befindet sich nun in einer vollwertigen Pre‑Boot‑Umgebung.

5. Boot Services - kontrollierte Firmware‑APIs

Während der DXE‑Phase stellt UEFI sogenannte Boot Services bereit. Das sind wohldefinierte Dienste, die später von Bootloadern oder direkt vom Betriebssystem genutzt werden können. Diese Dienste umfassen unter anderem:

• Speicherverwaltung
• Gerätezugriff
• Protokollierung
• Zeitfunktionen

Im Gegensatz zu BIOS‑Routinen sind diese Schnittstellen:

• formal spezifiziert
• versioniert
• konsistent implementierbar

UEFI ersetzt „historisch gewachsen“ durch „vertraglich definiert“.

6. Auswahl des Bootloads

Nun trifft UEFI eine Entscheidung, die beim BIOS implizit war: Was soll gestartet werden? UEFI denkt nicht in Bootsektoren, sondern in Boot‑Einträgen. Diese Einträge verweisen explizit auf:

• ein Medium
• ein Dateisystem
• eine ausführbare EFI‑Anwendung

Ein Betriebssystem wird also nicht durch Position, sondern durch Identität ausgewählt. Das erlaubt:

• mehrere Betriebssysteme parallel
• saubere Bootmanager
• reproduzierbare Startpfade

7. Laden der EFI‑Anwendung (Bootloader oder Kernel)

UEFI lädt nun eine sogenannte EFI‑Applikation. Das kann ein klassischer Bootloader sein oder - bei geeigneten Betriebssystemen - direkt der Kernel selbst. Diese Applikation:

• läuft bereits in einer klar definierten Umgebung
• nutzt UEFI‑Services
• arbeitet mit bekanntem Speicherlayout

Es gibt keinen Sprung ins Unbekannte, keinen blinden Vertrauensvorschuss auf Rohdaten.

8. Sicherheitsprüfungen (optional, aber zentral gedacht)

UEFI sieht explizit vor, dass geladene Komponenten überprüft werden können, bevor sie ausgeführt werden. Dabei kann geprüft werden:

• Herkunft
• Integrität
• Vertrauenswürdigkeit

Wichtig:
UEFI zwingt diese Prüfungen nicht auf - aber es macht sie architektonisch möglich. Das ist ein fundamentaler Unterschied zum BIOS, das keinerlei Startlogik kontrollieren kann.

9. Übergabe an das Betriebssystem

Irgendwann ist der Punkt erreicht, an dem UEFI seine Aufgabe erfüllt hat. Der Bootloader (oder Kernel) signalisiert, dass er bereit ist, die Kontrolle zu übernehmen. UEFI:

• beendet die Boot Services
• hinterlässt klar definierte Informationen
• zieht sich vollständig zurück

Ab diesem Moment existiert UEFI nicht mehr aktiv im System. Das Betriebssystem arbeitet autonom - allerdings mit einem sauberen, bekannten Ausgangszustand. Dieser Übergang ist explizit und sicher, nicht implizit und historisch.

10. UEFI vs. BIOS am Übergangspunkt

Hier wird der philosophische Unterschied besonders sichtbar:
Beim BIOS endet der Prozess mit einem Sprung ins Ungewisse.
Bei UEFI endet er mit einer formalen Machtübergabe.
Das Betriebssystem übernimmt ein System, nicht ein Versprechen.

Fazit: UEFI als kontrollierter Startprozess

Der UEFI‑Bootprozess ist länger, komplexer und sicherer als der BIOS‑Bootprozess - nicht aus Selbstzweck, sondern weil moderne Systeme es erfordern. UEFI:

• strukturiert den Start
• trennt Verantwortlichkeiten
• macht Sicherheit möglich
• skaliert mit Hardwareentwicklung

Es ersetzt das BIOS nicht, weil dieses schlecht war, sondern weil dessen Annahmen nicht mehr tragfähig waren. Damit ist UEFI nicht einfach der „nächste Bootloader“, sondern ein neues Fundament für den gesamten Software‑Stack.