Spezifikationen und Richtlinien¶

Die praktische Ausgestaltung der UEFI-Firmware eines PC-System wird in der Regel durch Spezifikationen und Richtlinien dreier Beteiligter bestimmt:

1. Spezifikation des UEFI-Forums

2. Spezifikationen Richtlinien zum Windows-Hardware-Kompatibilitätsprogramm

3. Firmware-Implementierung durch Systemhersteller

Anzeige vom Kernel unterstützter EFI-Optionen¶

grep CONFIG_EFI /boot/config-`uname -r` 

Überprüfung des Setzens der Kerneloptionen beim letzten Systemstart¶

journalctl -b -k --grep="efivars" 

Technische Merkmale des Boot-Modus¶

• Im Boot-Modus wird von der Firmware ein Bootmanager zur Verfügung gestellt, der es erlaubt, Betriebssystemloader direkt auf Dateisystemebene zu starten.

• Damit Betriebssystemloader-Einträge in der Firmware durch den Anwender bzw. durch das Betriebssystem eingetragen werden können, verfügen UEFI-Systeme über NVRAM-Chips die das Setzen dauerhafter Einstellungen erlauben, so dass sie auch erhalten bleiben, falls der Rechner ein mal von der Stromzufuhr getrennt wird.

• Im UEFI-Boot-Modus muss auf mindestens einem Datenträger im System eine EFI-Systempartition eingerichtet sein, welche die Loader-Dateien der einzelnen Betriebssysteme aufnimmt.

• Datenträger von denen im UEFI-Boot-Modus gestartet werden soll, sollten vorzugsweise mit einer GUID-Partitions-Tabelle (kurz: GPT) ausgestattet sein.

Diese Struktur hat gegenüber des BIOS-Boot-Modus damit den Vorteil, dass Betriebssystemloader nebeneinander auf der EFI-Systempartition abgelegt werden können, ohne sich gegenseitig in die Quere zu kommen.

Startablauf¶

Der Startablauf im UEFI-Boot-Modus ist dann grob betrachtet wie folgt:

1. Initialisierung der Firmware nach dem Einschalten des Systems und Einrichten der Pre-Boot-Umgebung.

2. Start der EFI-Boot-Services 🇬🇧.

3. Dynamisches Bereitstellen der Pfade /EFI/BOOT von der jeweils ersten EFI-Systempartition angeschlossener Datenträger im Bootmanager durch die UEFI-Boot-Services.

4. Entweder automatisches Laden des im EFI-Bootmanager definierten Standardeintrages oder es wird aufgrund von Benutzerinteraktion mit dem EFI-Bootmanager der vom Benutzer im EFI-Startmenü ausgewählte Eintrag von der Firmware versucht zu laden. Scheitert das Laden eines Eintrags, so wird der nächste Eintrag gemäß der UEFI-Startreihenfolge versucht zu laden.

5. Ausführen der durch den Eintrag im EFI-Bootmanager repräsentierten App – also im Falle des Eintrags für ein bestimmtes Betriebssystems in der Regel eine EFI-Bootloader-App – durch die Firmware.

6. Laden des Betriebssystem-Kernels durch die EFI-Bootloader-App.

7. Bereitstellung aller oder von Teilen der UEFI-Runtime-Services durch den Kernel an das Betriebssystem.

Startmenü¶

In der Praxis stellt die Firmware eines Rechners dem Anwender dafür ein EFI-Startmenü bereit, welches sich beim Systemstart durch Drücken einer bestimmten Taste aufrufen lässt. Zum Aufruf des EFI-Start-Menüs siehe im Detail Howto/Aufruf des Startmenüs und Firmware-Setups.

Das EFI-Startmenü enthält zum einen statische Einträge, die entweder vom Setup-Programm des jeweiligen Betriebssystems oder aber vom Anwender generiert werden. Daneben werden Einträge vom UEFI aber auch dynamisch durch Einlesen von dazu in der EFI-Spezifikation festgelegten Gerätepfaden erzeugt. Siehe dazu unten auch zum Verzeichnis BOOT.

Bearbeitung des EFI-Bootmanagers¶

Die Einträge des EFI-Bootmanagers lassen sich - sofern das Betriebssystem im UEFI-Boot-Modus gestartet wurde - über die vom UEFI bereitgestellten Variablen-Dienste vom jeweiligen Betriebssystem aus erstellen und bearbeiten. Auch Standard-Starteintrag, Reihenfolge der Einträge und Startbetriebssystem für den nächsten Neustart lassen sich so manipulieren:

• Unter Ubuntu existiert zu diesem Zweck das Programm efibootmgr.

• Unter Windows kann man Einträge mit dem vorinstallierten Programm bcdedit oder aber auch mit Programmen von Drittherstellern bearbeiten.

Technische Merkmale¶

• Partitionsnummer: 1 (Empfehlung!)

• Kennung: ef00

• Name: EFI System

• Dateisystem: FAT (Standard 32 bit)

• GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B

• Größe: 100-200 MiB

• Mountpunkt: /boot/efi

Verzeichnisstruktur¶

Die EFI-Systempartition verfügt über eine bestimmte Verzeichnisstruktur. Im Wurzelverzeichnis befindet sich nur das Verzeichnis EFI. Unterhalb von EFI existiert immer das Verzeichnis BOOT. Daneben existiert in der Regel mindestens ein Hersteller-Verzeichnis.

 ── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── mmx64.efi
    └── ubuntu
        ├── BOOTX64.CSV
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi

Variables-File-System¶

Unter Ubuntu werden die vom UEFI bereitgestellten EFI-Variablen über das im Kernel integrierte EFI-Variable-File-System-Modul (kurz efivarfs) im Verzeichnis /sys/firmware/efi/efivars während des Systemstarts bereitgestellt und stehen damit grundsätzlich zum Auslesen und Bearbeiten zur Verfügung. Siehe auch https://docs.kernel.org/filesystems/efivarfs.html 🇬🇧.

Die entsprechende Kerneloption CONFIG_EFI_VAR_FS ist im Ubuntu-Kernel standardmäßig aktiviert, wie man wie folgt überprüfen kann:

grep CONFIG_EFIVAR_FS /boot/config-`uname -r` 

CONFIG_EFIVAR_FS=y

Entsprechend wird beim Systemstart eine Kernelmeldung bei erfolgreicher Bereitstellung ausgegeben:

journalctl -b -k --grep="efivars" 

... kernel: ... Registered efivars operations

Struktur von /sys/firmware/efi/efivars¶

Bei den in /sys/firmware/efi/efivars bereitgestellten Variablen handelt es sich um die durch die global definierten Variablen. Der exakte Ort variiert leicht von Spezifikation zu Spezifikation.

Nicht alle in der Spezifikation aufgeführten Variablen müssen zwangsläufig auf allen Systemen zur Verfügung stehen.

Sofern auf dem System Secure Boot aktiviert ist, findet man unterhalb von /sys/firmware/efi/efivars z.B. außerdem die von Shim angelegten und genutzten Variablen für die Machine Owner Keys.

Daneben können dort je nach Hersteller und System weitere, spezifische Variablen vorzufinden sein.

Variablen-Format¶

Die Variablen bestehen aus einem auf einer GUID basierenden Namen, dem Inhalt und Attributen, welche angeben, wann auf die Variablen zugegriffen werden kann. Die Variablen liegen zudem in hexadezimaler Form vor.

Die Bezeichnung setzt sich dabei wie folgt zusammen:

• Name-{GUID-Namensraum}

Die jeweiligen GUID-Namensräume können sich dabei von System zu System unterscheiden.

Beispiel:

• BootCurrent-8be4cf61-93ca-11d2-aa1d-00b098032b7c

Die Attribute der Variablen und deren Inhalt kann man sich mittels des Programms efivar anzeigen lassen, wobei efivar bei der Variable zuerst die GUID und dann den Namen verwendet:

efivar -p -n GUID-NAME

Beispiel:
efivar -p -n 8be4cf61-93ca-11d2-aa1d-00b098032b7c-BootCurrent 

Weitere Details zu den EFI-Variablen kann man der jeweiligen UEFI-Spezifikation entnehmen.

Bearbeitung der EFI-Variablen¶

Nicht alle Variablen sind zur Bearbeitung vorgesehen, sondern eine ganze Reihe ist nur zum Auslesen bestimmt. Schon in der EFI-Spezifikation steht im übrigen, dass das Bearbeiten der Variablen sparsam gehandhabt werden sollte. Deswegen werden einige Variablen bei der Bereitstellung über das efivarfs-Modul mit dem immutable-Attribut (i) versehen, so dass sie vor versehentlicher Veränderung geschützt sind. Mit dem Befehl lsattr kann man sich anzeigen lassen, welche der Variablen auf diese Weise geschützt sind:

lsattr /sys/firmware/efi/efivars 

In der Regel gibt es auch nicht viele Anlässe, die Variablen überhaupt zu bearbeiten. Ausnahme bilden hier insbesondere die Variablen, die mit dem EFI-Bootmanagement zusammenhängen. Deren Bearbeitung ist im Normalfall unkritisch.

Werkzeuge¶

Da das Arbeiten mit hexadezimalen Variablen für Menschen unhandlich ist, existieren unter Ubuntu eine Reihe von Werkzeugen zum Anzeigen und Bearbeiten der Variablen:

• efibootmgr - Das Programm efibootmgr ist Bestandteil des gleichnamigen Paketes, welches unter einem Ubuntu, das im UEFI-Boot-Modus installiert wurde in der Regel bereits vorinstalliert ist. efibootmgr erlaubt die Bearbeitung aller mit dem EFI-Bootmanager im Zusammenhang stehender Variablen (siehe efibootmgr).

• efivar - Werkzeug allgemein zur Bearbeitung und zum Anzeigen von EFI-Variablen. Bestandteil des gleichnamigen Paketes, welches unter Ubuntu bei Bedarf installiert werden muss.

• efitools - Das Programmpaket efitools stellt eine Reihen von Werkzeugen zur Verfügung, die das Anzeigen und Bearbeiten der im NVRAM der Firmware existierenden Secure-Boot-Datenbanken ermöglicht. Das Pakte muss bei Bedarf erst installiert werden.

• mokutil - Das Programm mokutil dient zum Einrichten und Bearbeiten unter Ubuntu für die Nutzung von Secure Boot im NVRAM eingerichteten Machine Owner-Key-Datenbanken. Daneben kann es auch die vom UEFI für Secure Boot bereitgestellten Variablen auslesen und anzeigen.

Nutzungsmöglichkeiten¶

Die EFI-Variablen bieten einige bequeme Nutzungsmöglichkeiten aus dem laufenden Betriebssystem heraus. Die folgende Liste ist beispielhaft und keinesfalls abschließend:

systemctl reboot --firmware-setup 

Allgemeine Funktionsweise¶

Secure Boot definiert eine Public-Key-Infrastruktur, die es erlaubt, EFI-Anwendungen vor Ihrer Ausführung auf Vertrauenswürdigkeit auf Grundlage eines Paares von privaten und öffentlichen Schlüsseln oder anhand von Microsoft-Authenticode-Hashwerten zu überprüfen. Öffentliche Schlüssel werden dabei innerhalb eines Zertifikats abgelegt, dass neben dem Schlüssel selbst auch Informationen über den Einsatzzweck und den Zertifikats-Inhaber enthält und werden dann in der Firmware geschützt hinterlegt. Der private Schlüssel muss sicher vom Inhaber verwahrt werden und wird ausschließlich zum Signieren von EFI-Anwendungen, Betriebssystemkerneln oder Kernel-Modulen (Geräte-Treibern) verwendet.

Zur Ablage öffentlicher Zertifikate werden im NVRAM der Systemplattform zum einen die beiden Variablen db und dbx bereitgestellt:

• db: Bei der Variablen db handelt es sich um eine Datenbank, in der zum einen öffentliche Zertifikate verzeichnet sind, die zur Authentifizierung der Signaturen von EFI-Anwendungen, Betriebssystemkerneln und Kernelmodulen bzw. Treibern berechtigt sind. Daneben können dort auch Hash-Werte von vertrauenswürdigen Komponenten hinterlegt sein, die über keine Signatur verfügen.

• dbx: Bei der Variablen dbx handelt es sich um eine Blacklist-Datenbank. Hier können Hash-Werte von ausführbaren Dateien hinterlegt werden, die nicht als vertrauenswürdig gelten, weil z.B. Sicherheitslücken in ihnen entdeckt wurden und deren Ausführung deshalb explizit unterbunden werden soll. Oder es können öffentliche Zertifikate dort hinterlegt wurden, wenn ein Zertifikat widerrufen wurde.

Unter Ubuntu lässt sich der Inhalt der beiden Variablen mittels der beiden folgenden Kommandos anzeigen:

mokutil --db
mokutil --dbx 

Um die beiden Variablen db und dbx vor unerwünschter Manipulation zu schützen, implementiert Secure Boot außerdem noch eine Authentifizierungs-Infrastruktur:

• Platform Key: Der Platform Key (kurz: PK) begründet die Vertrauensstellung zwischen dem Platformbesitzer und der Firmware. Der Platform Key kennzeichnet die oberste Autorität in der Authentifizierungs-Infrastruktur. Praktisch schützt der PK den Zugriff auf den PK selbst und auf die Key Exchange Keys. Der Inhaber des PK ist dazu berechtigt,

  • den PK selbst zu aktualisieren oder zu löschen

  • Key Exchange Keys hinzuzufügen oder zu löschen

• Key Exchange Key: Der Key Exchange Key (kurz: KEK) begründet die Vertrauensstellung zwischen dem Betriebssystem und der Firmware. Der Inhaber eines KEK ist dazu berechtigt,

  • Änderungen an den Einträgen der db oder dbx vorzunehmen

PK und KEKs lassen sich unter Ubuntu mittels der beiden folgenden Befehle anzeigen:

mokutil --pk
mokutil --kek 

Beim Systemstart kann die Firmware so über die UEFI-Boot-Services, die Signatur der zu ladenden EFI-App - meist eine Betriebssystem-Loader-App - mit der dbx und der db vergleichen. Nur wenn die Signatur oder der Hash-Wert der App

• nicht in der dbx gelistet ist

• und in der db gelistet ist

dann führt die Firmware die EFI-App auch aus. Andernfalls verweigert die Firmware mit entsprechender Fehlermeldung die Ausführung.

Sobald der Betriebssystemloader oder der Betriebssystem-Kernel die Kontrolle übernimmt, indem er das Kommando zum Verlassen der UEFI-Boot-Services absetzt, aktiviert das UEFI die UEFI-Runtime-Services. Über die UEFI-Runtime-Services erhält der Betriebssystemloader bzw. -Kernel und alle folgenden Anwendungen und Dienste mittels der EFI-Varialbe-Services Zugriff auf die db- und dbx-Datenbanken.

Secure Boot im MS-Windows-Ökosystem¶

Wer einen Rechner erwirbt, dessen Hardware für den Betrieb von Microsoft Windows zertifiziert wurde und auf dem Windows vorinstalliert ist, trifft in aller Regel auf die folgende Secure-Boot-Infrastruktur:

• Der PK stammt vom Systemhersteller

• Es sind die folgenden KEKs eingrichtet

  • Microsoft Corporation KEK CA 2011

  • Microsoft Corporation KEK 2k CA 2023

  • Ein oder mehrere KEKs des Systemherstellers

In der Praxis sind in der db von PC-Systemen standardmäßig die folgenden öffentlichen Zertifikate hinterlegt:

• Microsoft Windows Production PCA 2011: Mit dem privaten Gegenstück dieses Zertifikats signiert Microsoft Windows und dessen von Microsoft bereitgestellten Komponenten.

• Microsoft Corporation UEFI CA 2011: Dies ist das öffentliche Gegenstück des Microsoft Corporation Third Party Marketplace Zertifikats. Über den Thrid Party Marketplace ist es für andere Firmen - wie z.B. auch Canonical - möglich, sich EFI-Anwendungen signieren zu lassen, so dass diese dann auf Rechnern mit vorinstallierten Windows auch ohne Eingriff des Endanwenders bei aktiviertem Secure Boot ausgeführt werden können.

• Ein oder mehrere Zertifikate des Rechner-Herstellers: Diese Zertifikate werden von den Herstellern für das Signieren von EFI-Anwendungen wie z.B. in das UEFI integrierte Wiederherstellungs-, Hardware-Diagnose-Anwendungen oder Firmware-Update-Anwendungen genutzt.

Welche Zertifikate jeweils konkret auf einem Rechner vorinstalliert sind, kann unter Ubuntu mit mokutil überprüft werden:

mokutil --db 

Wie Microsoft signiert¶

Zum Laden eines Bootloaders oder Betriebssystemskernel auf einem für Microsoft Windows zertifizierten Systems mit aktiviertem Secure Boot müssen diese theoretisch einfach nur mit dem privaten Schlüssel des oben genannten Microsoft Corporation UEFI CA 2011 von Microsoft signiert werden.

Allerdings müssten sich die Distributoren dann bei jeder Änderung an den von Ihnen ausgerollten Bootloadern, Kerneln und Kernelmodulen diese immer wieder neu von Microsoft signieren lassen. Das ist auf Dauer unpraktikabel, weil dadurch z.B. die Bereitstellung wichtiger Sicherheitsupdates weiter verzögert wird.

Daher werden die Startkomponenten von Linux-Distributionen wie Bootloader, Kernel und Kernel-Module in der Praxis im Secure-Boot-Kontext nicht direkt von Microsoft signiert.

Shim-Bootloader und Machine Owner Key (MOK)¶

Um eine Linux-Distribution nun dennoch auf einem Windows-zertifizierten Rechner mit aktiviertem Secure Boot weitestgehend ohne Zutun Dritter - sei es durch Microsoft und Systemhersteller auf der einen Seite oder aber auch dem technisch weniger versierten Endanwender auf der anderen Seite - starten zu können, hat Matthew Garret das Konzept von Shim (engl.: Distanz- oder Unterlegscheibe) und den Machine Owner Keys (kurz: MOK) erdacht.

Shim ist eine ganz simple EFI-Bootloader-App, die nichts anderes macht, als die eigentlichen Distributions eigenen Bootloader aus den dafür vorgehsehen Herstellerverzeichnissen auf der EFI-Systempartition beim Systemstart zur Ausführung zu bringen.

Die Distributoren lassen sich nun jeweils ihren eigenen Shim-Loader von Microsoft signieren, aber nur eben diesen. Damit müssen die Distributoren Shim künftig nur erneut signieren lassen, falls Shim selbst verändert werden muss - was aufgrund der Einfachheit seiner Aufgabe viel seltner vorkommen wird.

Der signierte Bootloader Shim alleine sorgt aber erst mal nur dafür, dass die betreffende Linux-Distribution auf einem Rechner mit aktivierten Secure Boot überhaupt starten kann. Eine Nutzung von Secure Boot durch die Distribution ist damit aber noch nicht möglich, weil die öffentlichen Zertifikate der Distributoren nicht ohne Zutun der dafür Berechtigten in der Zertifikatsdatenbank der Rechner-Firmware hinterlegt werden können.

Deswegen wird bei einer Linux-Distribution die Shim nutzt neben Shim selbst noch die Machine-Owner-Key-Infrastruktur eingerichtet. Hierbei handelt es sich um authentifizierte EFI-Variablen analog zu den Secure-Boot-Datenbank-Variablen der Firmware.

In den MOK-Datenbanken kann nun der Distributor einerseits und der "Machine Owner" - also der Endanwender - andererseits, Zertifikate ablegen und widerrufen, ohne dass es dabei auf die Berechtigungen aus der Secure-Boot-Datenbank in der Rechner-Firmware ankommt.

Damit ist dann die Lücke zwischen aktiviertem Secure Boot und dem Interesse von Linux-Distributoren, nämlich ihre Distributionen weitestgehend ohne Zutun Dritter störungsfrei zur Ausführung bringen zu können, überbrückt.

Secure-Boot-Umsetzung von Ubuntu¶

Da Linux-Distributionen und damit auch Ubuntu in einer Vielzahl von Fällen auf Computern installiert werden, auf denen die im vorhergehenden Abschnitt genannten Gegebenheiten zutreffen, stehen Distributoren vor der Herausforderung, wie Ihre Distributionen und die Medien zur Installation Ihrer Distributionen auf Systemen mit aktivierten Secure Boot ohne Eingriff seitens des Endanwenders starten können.

Ubuntu setzt für den problemfreien Start des Ubuntu-Installations-Mediums und eines installierten Ubuntu auf einem Rechner mit aktivierten Secure Boot auf Shim und dessen MOK-Infrastruktur (siehe #Shim-und-MOK---Distanzscheibe-zwischen-Microsoft-Secure-Boot-und-Linux-Distributionen). Das spiegelt auch der Verzeichnisinhalt der EFI-Systempartition wieder:

└── ubuntu
    ├── BOOTX64.CSV
    ├── grub.cfg
    ├── grubx64.efi
    ├── mmx64.efi
    └── shimx64.efi

Bei shimx64.efi handelt es sich dabei um die explizit für Canonical von Microsoft signierte Shim-Loader-EFI-App, die dann den eigentlichen Ubuntu Bootloader GRUB 2 /EFI/ubuntu/grubx64.efi zur Ausführung bringt. Die /EFI/ubuntu/grubx64.efi ist dabei dann nicht mehr von Microsoft signiert, sondern von Canonical. Das öffentliche Canonical Zertifikat wird bei der Intallation von Ubuntu in der von Shim im NVRAM der Firmware eingerichteten MOK-Infrastruktur hinterlegt, so dass es zum sicheren Abgleich der in den Systemstart involvierten Elemente genutzt werden kann. Dies betrifft standardmäßig momentan (Stand 2024):

• Den Bootloader GRUB 2

• Die Ubuntu Kernel-Images

• Unter Ubuntu gentutzte Kernel-Module

Dies betrifft aber derzeit (Stand 2024) nicht:

• Die in den Systemstart ebenfalls eingebundene initrd.

Überprüfung des Secure-Boot-Status¶

mokutil --sb-state 

bootctl status --no-pager 2>&1 | grep -E 'Secure Boot|Setup Mode|TPM2 Support|Boot into FW' 

od --address-radix=n --skip-bytes=4 --format=u1 /sys/firmware/efi/efivars/SecureBoot-* 

od --address-radix=n --skip-bytes=4 --format=u1 /sys/firmware/efi/efivars/SetupMode-* 

Gerätepfade nach BIOS-Boot-Spezifikation¶

UEFI-Firmware kann daher grundsätzlich auch Gerätepfade nach BIOS-Boot-Spezifikation ⮷ 🇬🇧 bereitstellen. Siehe dazu den Abschnitt "BIOS Boot Specification Device Path" der jeweiligen UEFI-Spezifikation.

Zu beachten ist dabei unbedingt, dass die Bereitstellung von Gerätepfaden nach BIOS-Boot-Spezifikation durch das UEFI nur erfolgen darf, sofern Secure Boot deaktiviert ist! Die gleichzeitige Nutzung von Secure Boot und Gerätepfaden nach BIOS-Boot-Spezifikation ist sinnvollerweise also ausgeschlossen! Siehe dazu den Abschnitt "BIOS Boot Specification Device Path" der jeweiligen Spezifikation im Zusammenhang mit den Abschnitt "System.Fundamentals.Firmware.UEFILegacyFallback".

Deshalb wird in der Praxis die Bereitstellung von Gerätepfaden nach BIOS-Boot-Spezifikation innerhalb der UEFI-Firmware durch ein separat zuschaltbares Modul realisiert, welches in der Regel als Compatibility Support Module (kurz: CSM) bezeichnet wird. Da das Bereitstellen von Gerätepfaden nach BIOS-Boot-Spezifikation aus UEFI-Sicht das Verwenden der alten Bootmethode bedeutet, werden die so eingefügten Gerätepfade - angelehnt an den englischen Begriff "legacy" (deutsch: alt) - häufig auch als "Legacy Boot Options" tituliert.

Ist das CSM erfolgreich aktiviert, dann verhält sich die Firmware beim Systemstart, wie BIOS-Firmware, d.h.:

• Es werden Gerätepfade nach BIOS-Boot-Spezifikation für den Systemstart bereitgestellt.

• Datenträger von denen im BIOS-Boot-Modus gestartet werden soll, sollten im MBR-Partitions-Schema eingerichtet sein.

• Es wird eine 16-bit-Umgebung (Protected Mode) während der Systemstartphase emuliert.

• Es können Betriebssysteme installiert und gestartet werden, die mit dem UEFI-Boot-Modus nicht kompatibel sind.

• Der in den Startsektoren der ausgewählten Startdatenträger enthaltene Code wird ohne jedwede Prüfung ausgeführt.

Bereitstellung neben dem UEFI-Bootmodus¶

Die Bereitstellung der Gerätepfade nach BIOS-Boot-Spezifikation erfolgt bei Aktivierung des CSM häufig neben der Bereitstellung der UEFI-kompatiblen Gerätepfade für den UEFI-Bootmodus.

Unterstützt ein Datenträger den Start sowohl im UEFI-Bootmodus als auch im BIOS-Bootmodus - was auf viele Betriebssystem-Installationsdatenträger und auch auf das Ubuntu-Installations-Medium zutrifft -, so werden im EFI-Menü für den betreffenden Datenträger auch zwei Starteinträge erzeugt.

Der Anwender muss hier also bei der Startauswahl unter Umständen darauf achten, dass er den Eintrag für den gewünschten Modus (UEFI-Boot oder BIOS-Boot) ausdrücklich auswählt, andernfalls installiert er das Betriebssystem im falschen Modus. Wie die Unterscheidung der Einträge im EFI-Startmenü dabei gestaltet ist, ist leider von Firmware zu Firmware unterschiedlich. Im folgenden Beispiel:

Compatibility Support Module American Megatrends Inc. (AMI)

Unterscheidung von UEFI-Boot-Modus und BIOS-Boot-Modus¶

Ob das jeweilige Betriebssystem oder das Live-Medium im UEFI-Boot- oder BIOS-Boot-Modus gestartet wurde, lässt unter Ubuntu unter anderem mit einem Blick in das Verzeichnis /sys/firmware feststellen:

• Ist das Verzeichnis /sys/firmware/efi vorhanden, so wurde das System im UEFI-Boot-Modus gestartet.

• Ist das Verzeichnis /sys/firmware/efi nicht vorhanden, so wurde das System im BIOS-Boot-Modus gestartet.

Mit folgendem Terminal-Kommando lässt sich diese Aufgabe in einem Rutsch erledigen:

test -d /sys/firmware/efi && echo UEFI-Modus || echo BIOS-Modus 

Intern¶

• EFI Bootmanagement Übersicht zur Artikelserie

  • EFI Installieren - Hinweise vor einer und zur Installation

  • EFI Deinstallieren - Selektives Entfernen eines Betriebssystemes

  • EFI Nachbearbeitung - Hinweise und Maßnahmen nach einer Installation

  • EFI Modus umstellen - Umstellung der Boot-Modi von (U)EFI nach BIOS

  • efibootmgr - (U)EFI-Menü einstellen und prüfen

  • EFI Problembehebung - eine Sammlung von Erfahrungen und Abhilfen

  • EFI USB-Stick - Einen USB-Stick für UEFI aufbereiten

• Übersicht Live-USB - Auflistung von Programmen, mit dem man eine ISO-Datei auf einen USB-Stick bringen kann

Extern¶

• UEFI Spezifikation 🇬🇧 - Aufbau und Grundsätze

• UEFI - Unified Extensible Firmware Interface

• NVRAM - Non-Volatile Random-Access Memory

• PE-Format - Spezifikation des Microsoft Portable-Executable-Formats auf learn.microsoft.com

• MS-PE-Authenticode-Spezifikation 🇬🇧 - Spezifikation des Microsoft-Authenticode-Formats für Microsoft Portable Executeables

• Windows Anleitung zum Erstellen und Verwalten von Sicheren Startschlüsseln - Windows Anleitung zum Erstellen und Verwalten von Sicheren Startschlüsseln auf learn.microsoft.com