Falls auf »@saved« gesetzt, wird der ausgewählte Eintrag bei jedem Systemstart als EFI-Variable gesetzt und automatisch beim nächsten Mal, wenn das Systemstartprogramm startet, ausgewählt.

Tabelle 1. Automatisch erkannte Einträge werden die folgenden Namen verwenden:

Es werden die Glob-Platzhalterzeichenmuster »?«, »*« und »[…]« (einschließlich Bereiche) unterstützt. Beachten Sie, dass diese Muster die gleiche Syntax wie glob(7) verwenden, aber nicht alle Funktionalitäten unterstützen. Insbesondere die Verneinung von Mengen und benannte Zeichenklassen werden nicht unterstützt. Der Vergleich ignoriert die Groß-/Kleinschreibung bei der Eintragskennung (wie durch bootctl list angezeigt).

Falls auf »menu-hidden« oder »0« (die Vorgabe) (die Vorgabe) gesetzt, wird kein Menü angezeigt und der Standardeintrag sofort gestartet. Das Menü kann durch Drücken und Halten einer Taste, bevor Systemd-boot aufgerufen wird, angezeigt werden. Durch Setzen von »menu-force« wird die Zeitüberschreitung deaktiviert und gleichzeitig das Menü immer angezeigt.

0

1

2

auto

max

keep

Akzeptiert entweder »off«, »manual« oder »force«. Steuert die Registrierung der sicheren Systemladeschlüssel. Falls auf »off« gesetzt erfolgt keinerlei Aktion. Falls auf »manual« gesetzt (die Vorgabe) und die UEFI-Firmware sich im Einrichtungsmodus befindet, dann werden die Einträge, um die Secure-Boot-Variablen manuell zu registrieren, im Systemstartmenü erstellt. Falls auf »force« gesetzt und falls zusätzlich ein Verzeichnis /loader/keys/auto/ auf dem ESP existiert, dann werden die Schlüssel in diesem Verzeichnis automatisch registriert.

Die verschiedenen Variablenmengen können unter /loader/keys/NAME eingerichtet werden, wobei NAME als Name des Eintrags verwandt wird. Dies ermöglicht die Auslieferung mehrerer Gruppen von Secure-Boot-Variablen und die Auswahl zur Laufzeit, welche registriert werden sollen.

Die unterstützten Secure-Boot-Variablen sind einer für die Datenbank der authorisierten Abbilder, eine für den Schlüsselaustauschschlüssel (KEK) und eine für den Plattformschlüssel (PK). Für weitere Informationen lesen Sie bitte die UEFI-Spezifikation[2], unter »Secure Boot and Driver Signing«. Eine anderer Ressource, die das Zusammenwirken der verschiedenen Variablen beschreibt, ist die EDK2-Dokumentation[3].

Die vollständige Menge der UEFI-Variablen enthält db.auth, KEK.auth und PK.auth. Beachten Sie, dass diese Dateien authentifizierte UEFI-Variablen sein müssen. Sie finden weiter unten ein Beispiel, wie sie diese von regulären X.509-Schlüsseln erstellen können.

uuid=$(systemd-id128 new --uuid)
for key in PK KEK db; do


  openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.crt"


  openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"


  cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl"
done
for key in MicWinProPCA2011_2011-10-19.crt MicCorUEFCA2011_2011-06-27.crt MicCorKEKCA2011_2011-06-24.crt; do


  curl "https://www.microsoft.com/pkiops/certs/${key}" --output "${key}"


  sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%crt}esl" "${key}"
done
# Optional Microsoft Windows Production CA 2011 hinzufügen (benötigt, um in Windows zu starten).
cat MicWinProPCA2011_2011-10-19.esl >> db.esl
# Optional Microsoft Corporation UEFI CA 2011 hinzufügen (für Firmware-Treiber / Options-ROMS
# und Systemstartprogramme Dritter (einschließlich shim). Dies wird auf echter Hardware
# nachdrücklich empfohlen, da Sie ansonsten ihr System weich lahmlegen (siehe nächsten Absatz).
cat MicCorUEFCA2011_2011-06-27.esl >> db.esl
# Optional Microsoft Corporation KEK CA 2011 hinzufügen. Empfohlen, falls einer der
# Microsoft-Schlüssel verwandt wird, da die offizielle UEFI-Widerrufsdatenbank mit diesem
# Schlüssel signiert ist. Die Wiederrufsdatenbank kann mit fwupdmgr(1) aktualisiert
# werden.
cat MicCorKEKCA2011_2011-06-24.esl >> KEK.esl
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth


        

Diese Funktionalität wird als gefährlich betrachtet, da selbst wenn alle benötigten Dateien mit den geladenen Schlüsseln signiert wurden, einige für den korrekten Betrieb des Systems benötigte Dateien dies nicht sind. Dies ist insbesondere für Options-ROMS (z.B. für Speicherkontroller oder Graphikkarten) der Fall. Siehe Sicherer Systemstart und Options-ROMs[4] für weitere Details.

Umgeht die BitLocker-Anforderung bezüglich eines Wiederherstellungsschlüssels, wenn das Systemstartprogramm aktualisiert wird (standardmäßig deaktiviert).

Versucht, BitLocker-verschlüsselte Laufwerke zusammen mit einem aktiven TPM zu erkennen. Falls beide gefunden werden und »Windows Boot Manager« im Systemstartmenü ausgewählt wird, wird die EFI-Variable »BootNext« gesetzt und das System neu gestartet. Die Firmware wird dann den Windows-Systemstart-Manager direkt starten und die TPM PCRs in den erwarteten Zuständen belassen, so dass Windows die Verschlüsselungsschlüssel entsiegeln kann. Dies ermöglicht es, systemd-boot(7) zu aktualisieren, ohne einen Wiederherstellungsschlüssel für das Entsperren von BitLocker-Laufwerken bereitzustellen.

Beachten Sie, dass die von Windows verwandten PCRs mit der Gruppenrichtlinie »Configure TPM platform validation profile for native UEFI firmware configurations« unter »Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption« konfiguriert werden können. Wenn der sichere Systemstart aktiviert ist, sollte das Ändern der PCRs »0,2,7,11« unproblematisch sein. Der TPM-Schlüsselschutz muss entfernt und dann wieder hinzugefügt werden, damit die PCRs auf einem bereits verschlüsselten Laufwerk geändert werden können. Falls PCR 4 nicht eingemessen wird, kann diese Einstellung deaktiviert werden, um das Starten in Windows zu beschleunigen.

Siehe Zufallsstartwerte[5] für weitere Informationen.

# /boot/efi/loader/loader.conf
timeout 0
default 01234567890abcdef1234567890abdf0-*
editor no