Provided by: manpages-de_4.21.0-2_all 
BEZEICHNUNG
systemd-stub, sd-stub, linuxx64.efi.stub, linuxia32.efi.stub, linuxaa64.efi.stub - Ein einfacher
UEFI-Kernel-Systemstartrumpf
ÜBERSICHT
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /usr/lib/systemd/boot/efi/linuxia32.efi.stub /usr/lib/systemd/boot/efi/linuxaa64.efi.stub ESP/…/foo.efi.extra.d/*.addon.efi ESP/.../foo.efi.extra.d/*.cred ESP/.../foo.efi.extra.d/*.raw ESP/loader/addons/*.addon.efi ESP/loader/credentials/*.cred
BESCHREIBUNG
systemd-stub (gespeichert auf Platte in den architekturabhängigen Dateien linuxx64.efi.stub,
linuxia32.efi.stub, linuxaa64.efi.stub) ist ein einfacher UEFI-Systemstartrumpf. Ein
UEFI-Systemstartrumpf ist ein Stück Code, das an ein Linux-Kernel-Programmabbild angehängt wird und in
der UEFI-Firmwareumgebung ausgeführt wird, bevor in die Linux-Kernelumgebung übergewechselt wird. Der
UEFI-Systemstartrumpf stellt sicher, dass ein Linux-Kernel als reguläres UEFI-Programm ausgeführt wird.
Er ist in der Lage, verschiedene vorbereitende Aktionen durchzuführen, bevor das System in die Linux-Welt
umgeschaltet wird.
Der UEFI-Systemstartrumpf schaut innerhalb des UEFI-PE-Programms selbst nach verschiedenen Ressourcen für
den Kernelaufruf. Dies ermöglicht die Kombination verschiedener Ressourcen innerhalb eines einzigen
PE-Programmabbilds (das normalerweise »Unified Kernel Image« (vereinigtes Kernelabbild oder kurz »UKI«)
genannt wird), welches dann selbst wieder über UEFI SecureBoot als ganzes signiert werden kann, und damit
alle einzelnen Ressourcen auf einmal abdeckt. Insbesondere kann er folgendes enthalten:
• Nach dem ELF-Linux-Kernelabbild wird im PE-Abschnitt ».linux« des ausführbaren Abbilds gesucht.
• Betriebssystemveröffentlichungsinformationen, d.h. die Datei os-release(5) des Betriebssystems, zu
dem der Kernel gehört, im Abschnitt ».osrel«.
• Nach der an den aufgerufenen Kernel zu übergebenen Kernelbefehlszeile wird im PE-Abschnitt ».cmdline«
gesucht.
• Die Initrd wird aus dem PE-Abschnitt ».initrd« geladen.
• Nach der vor Aufruf des Kernels anzuzeigenden Systemstartgraphik (im Windows-.BMP-Format) wird im
PE-Abschnitt »&.splash« gesucht.
• Nach dem kompilierten binären DeviceTree wird im PE-Abschnitt ».dtb« gesucht.
• Kernelversionsinformationen, d.h. die Ausgabe von uname -r für den im UKI enthaltenen Kernel, im
PE-Abschnitt ».uname«.
• SBAT[1] revocation metadata, in the ".sbat" PE section.
• Eine Gruppe kryptographischer Signaturen im JSON-Format für die erwarteten TPM2-PCR-Werte, wenn
dieser Kernel gestartet wird, im Abschnitt ».pcrsig«. Dies ist zur Implementierung von
TPM2-Richtlinien nützlich, die Plattenverschlüsselung und ähnliches an Kernel binden, die mit einem
bestimmten Schlüssel signiert wurden.
• Ein Richtlinien-Schlüssel im PEM-Format, der auf diese TPM2-PCR-Signaturdaten im Abschnitt ».pcrpkey«
passt.
Falls UEFI-SecureBoot aktiviert und der Abschnitt ».cmdline« in dem ausgeführten Abbild vorhanden ist,
werden alle Versuche, die Kernelbefehlszeile durch Übergabe anderer Aufrufparameter an das EFI-Programm
außer Kraft zu setzen, ignoriert. Um daher die Außerkraftsetzung der Kernelbefehlszeile zu erlauben,
deaktivieren Sie entweder UEFI-SecureBoot oder nehmen Sie keine Kernelbefehlszeile in den PE-Abschnitt in
der Kernelabbilddatei auf. Falls eine Befehlszeile über EFI-Aufrufparameter an das EFI-Programm
akzeptiert wird, dann wird sie in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist).
Falls in dem Abschnitt ».dtb« ein DeviceTree eingebettet ist, ersetzt er einen bestehenden DeviceTree in
der entsprechenden EFI-Konfigurationstabelle. Systemd-stub wird die Firmware über das
»EFI_DT_FIXUP_PROTOCOL« nach hardwarespezifischen Korrekturen für den DeviceTree befragen.
Der Inhalt der sieben dieser acht PE-Abschnitte wird in TPM PCR 11 eingemessen, der anderweitig nicht
verwandt wird. Daher kann er ohne großen Aufwand vorberechnet werden. Der Abschnitt »&.pcrsig« wird in
diese Messung nicht eingeschlossen, da er dazu gedacht ist, die Signaturen der erwarteten Ergebnisse für
diese Messungen zu enthalten, d.h. die Ausgaben dieser Messaktion und kann daher nicht gleichzeitig deren
Eingabe sein.
Wenn ».pcrsig« und/oder ».pcrpkey« in einem vereinigten Kernelabbild vorhanden sind, werden ihre Inhalte
an den gestarteten Kernel in einem synthetisierten Initrd-CPIO-Archiv übergeben, das sie unter den
Dateien .extra/tpm2-pcr-signature.json und /.extra/tpm2-pcr-public-key.pem ablegt. Typischerweise stellt
eine tmpfiles.d(5)-Zeile dann sicher, das sie nach /run/systemd/tpm2-pcr-signature.json und
/run/systemd/tpm2-pcr-public-key.pem kopiert werden, wo sie zugreifbar bleiben, auch nachdem das System
aus der Initrd-Umgebung in das Dateisystem des Rechners übergegangen ist. Werkzeuge wie
systemd-cryptsetup@.service(8), systemd-cryptenroll(1) und systemd-creds(1) werden diese Dateien
unterhalb dieser Pfade automatisch verwenden, um geschützte Ressourcen (verschlüsselte Dateisysteme oder
Zugangsberechtigungen) zu entsperren oder Verschlüsselungen an gestartete Kernel zu binden.
For further details about the UKI concept, see the UKI specification[2].
BEGLEITDATEIEN
Der UEFI-Systemstartrumpf systemd-stub sammelt automatisch drei Arten von zusätzlichen
Hilfs-Begleitdateien, die optional in den Ergänzungsverzeichnissen auf der gleichen Partition wie das
EFI-Programm abgelegt werden, erstellt ein cpio-Initrd-Archiv daraus und übergibt sie an den Kernel.
Konkret:
• Für ein Kernelprogramm namens foo.efi wird nach Dateien mit der Endung .cred in einem Verzeichnis
namens foo.efi.extra.d/ daneben gesucht. Falls das Kernelprogramm einen Zähler zum Zwecke der
Automatischen Systemstartbewertung[3] verwendet, wird dieser Zähler ignoriert. Beispielsweise wird
foo+3-0.efi im Verzeichnis foo.efi.extra.d/ nachschauen. Von auf diese Art gefundenen Dateien wird
ein cpio-Archiv erstellt und sie werden im Verzeichnis /.extra/credentials/ in der
Initrd-Dateihierarchie abgelegt. Die Haupt-Initrd kann dann auf sie in dem Verzeichnis zugreifen.
Dies ist dazu gedacht, zusätzliche, verschlüsselte, authentifizierte Zugangsberechtigungen zum
Einsatz mit LoadCredentialEncrypted= in der UEFI-Systempartition zu speichern. Siehe systemd.exec(5)
und systemd-creds(1) für Details über verschlüsselte Zugangsberechtigungen. Das erstellte cpio wird
in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist).
• Ähnlich werden foo.efi.extra.d/*.raw-Dateien in einem cpio-Archiv gepackt und im Verzeichnis
/.extra/sysext/ in der Initrd-Dateihierarchie abgelegt. Dies ist zur Übergabe zusätzlicher
Systemerweiterungsabbilder an die Initrd gedacht. Siehe systemd-sysext(8) für Details über
Systemerweiterungsabbilder. Das erstellte cpio, das diese Systemerweiterungsabbilder enthält, wird in
TPM PCR 13 eingemessen (falls ein TPM vorhanden ist).
• Ähnlich werden Dateien foo.efi.extra.d/*.addon.efi geladen und als PE-Programme verifiziert und ein
Abschnitt ».cmdline« wird aus ihnen ausgelesen. Erweiterungen sind dazu gedacht, zusätzliche
Kernelbefehlszeilenparameter oder Devicetree-Datenblöcke weiterzugeben, unabhängig vom gestarteten
Kernel. Beispielsweise erlaubt dies Lieferanten, plattformspezifische Konfiguration auszuliefern.
In case Secure Boot is enabled, these files will be validated using keys in UEFI DB, Shim's DB or
Shim's MOK, and will be rejected otherwise. Additionally, if the both the addon and the UKI contain a
a ".uname" section, the addon will be rejected if they do not match exactly. It is recommended to
always add a ".sbat" section to all signed addons, so that they may be revoked with a SBAT policy
update, without requiring blocklisting via DBX/MOKX. The ukify(1) tool will add a SBAT policy by
default if none is passed when building addons. For more information on SBAT see Shim
documentation[1].
Addon files are sorted, loaded, and measured into TPM PCR 12 (if a TPM is present) and appended to
the kernel command line. UKI command line options are listed first, then options from addons in
/loader/addons/*.addon.efi, and finally UKI-specific addons. Device tree blobs are loaded and
measured following the same algorithm. Addons are always loaded in the same order based on the
filename, so that, given the same set of addons, the same set of measurements can be expected in
PCR12. However, note that the filename is not protected by the PE signature, and as such an attacker
with write access to the ESP could potentially rename these files to change the order in which they
are loaded, in a way that could alter the functionality of the kernel, as some options might be
order-dependent. If you sign such addons, you should pay attention to the PCR12 values and make use
of an attestation service so that improper use of your signed addons can be detected and dealt with
using one of the aforementioned revocation mechanisms.
• /loader/credentials/*.cred-Dateien werden in ein cpio-Archiv gepackt und im Verzeichnis
/.extra/global_credentials/ der Initrd-Dateihierarchie abgelegt. Dies ist zur Übergabe zusätzlicher
Zugangsberechtigungen an die Initrd gedacht, unabhängig von dem gestarteten Kernel. Das erstellte
cpio wird in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist).
• Additionally, files /loader/addons/*.addon.efi are loaded and verified as PE binaries, and ".cmdline"
and/or ".dtb" sections are parsed from them. This is supposed to be used to pass additional command
line parameters or Devicetree blobs to the kernel, regardless of the kernel being booted.
Diese Mechanismen können zum Parametrisieren und Erweitern vertrauenswürdiger (d.h. signierter),
unveränderbarer Initrd-Abbilder auf eine recht sichere Art und Weise verwandt werden: alle in ihnen
erhaltene Daten werden in TPM PCRs eingemessen. Beim Zugriff sollten sie weiter validiert werden: Im
Falle der Zugangsberechtigungen durch Entschlüsselung/Authentifizierung mittels TPM, wie das über
systemd-creds encrypt -T (siehe systemd-creds(1) für Details) offengelegt wird; im Falle der
Systemerweiterungsabbilder mittels signierter Verity-Abbilder.
TPM-PCR-HINWEISE
Beachten Sie, dass beim Aufruf eines vereinigten Kernels mittels systemd-stub die Firmware ihn als ganzes
in TPM PCR 4 einmessen wird und dabei alle eingebetteten Ressourcen wie den Stub-Code selbst, den
Kernelkern, die eingebettete Initrd und die Kernelbefehlszeile abdecken wird (die vollständige Liste
finden Sie weiter oben).
Beachten Sie auch, dass der Linux-Kernel alle Initrds, die er empfängt, in TPM PCR 9 einmessen wird. Dies
bedeutet, dass jede Art von Initrd zwei oder drei Mal gemessen wird: die im Kernel-Abbild eingebettete
Initrd wird in PCR 4, PCR 9 und PCR 11 eingemessen; die aus den Zugangsberechtigungen synthetisierte
Initrd wird sowohl in PCR 9 als auch in PCR 12 eingemessen; die aus den Systemerweiterungen
synthetisierte Initrd wird sowohl in PCR 4 als auch PCR 9 eingemessen. Zusammenfassend können die
Betriebssystemressourcen und die PCRs, in die sie eingemessen werden, wie folgt zusammengefasst werden:
Tabelle 1. Zusammenfassung von Betriebssystem-Ressourcen-PCR
┌─────────────────────────────────────────────┬────────────┐
│Betriebssystemressource │ Mess-PCR │
├─────────────────────────────────────────────┼────────────┤
│Code von systemd-stub (der │ 4 │
│Einstiegspunkt für das vereinigte │ │
│PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│Kern-Kernelcode (eingebettet in das │ 4 + 11 │
│vereinigte PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│Betriebssystemveröffentlichungsinformationen │ 4 + 11 │
│(eingebettet in das vereinigte │ │
│PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│Haupt-Initrd (eingebettet in das vereinigte │ 4 + 9 + 11 │
│PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│Standard-Kernel-Befehlszeile (eingebettet in │ 4 + 11 │
│das vereinigte PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│Kernel-Befehlszeile außer Kraft setzen │ 12 │
├─────────────────────────────────────────────┼────────────┤
│Startbild (eingebettet in das vereinigte │ 4 + 11 │
│PE-Programm) │ │
├─────────────────────────────────────────────┼────────────┤
│TPM2-PCR-Signatur-JSON (eingebettet in das │ 4 + 9 │
│vereinigte PE-Programm, synthetisiert in die │ │
│Initrd) │ │
├─────────────────────────────────────────────┼────────────┤
│TPM2-PCR-PEM öffentlicher Schlüssel │ 4 + 9 + 11 │
│(eingebettet in das vereinigte PE-Programm, │ │
│synthetisiert in die Initrd) │ │
├─────────────────────────────────────────────┼────────────┤
│Zugangsberechtigungen (synthetisierte Initrd │ 9 + 12 │
│aus Begleitdateien) │ │
├─────────────────────────────────────────────┼────────────┤
│Systemerweiterungen (synthetisierte Initrd │ 9 + 13 │
│aus Begleitdateien) │ │
└─────────────────────────────────────────────┴────────────┘
EFI-VARIABLEN
Die folgenden EFI-Variablen werden unter der Lieferanten-UUID »4a67b082-0a4c-41cf-b6c7-440b29bb8c4f« für
die Kommunikation zwischen dem Systemstartrumpf und dem Betriebssystem definiert, gesetzt und gelesen:
LoaderDevicePartUUID
Enthält die Partitions-UUID der EFI-Systempartition von der das EFI-Abbild ausgeführt wurde.
systemd-gpt-auto-generator(8) verwendet diese Information, um automatisch die Platte zu finden, von
der gestartet wurde, um verschiedene andere Partitionen auf der gleichen Platte automatisch zu
erkennen.
Hinzugefügt in Version 250.
LoaderFirmwareInfo, LoaderFirmwareType
Kurze Firmware-Informationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten.
Hinzugefügt in Version 250.
LoaderImageIdentifier
Der Pfad zum EFI-Programm, relativ zum Wurzelverzeichnis der EFI-Systempartition. Verwenden Sie
bootctl(1), um diese Daten zu betrachten.
Hinzugefügt in Version 250.
StubInfo
Kurze Rumpfinformationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten.
Hinzugefügt in Version 250.
StubPcrKernelImage
Der PCR-Registerindex, in das das Kernelabbild, Initrd-Abbild, der Startbildschirm, die
Devicetree-Datenbank und die eingebettete Befehlszeile eingemessen werden, formattiert als dezimale
ASCII-Zeichenkette (z.B. »11«). Diese Variable ist gesetzt, falls eine Messung erfolgreich
abgeschlossen werden konnte und verbleibt ansonsten nicht gesetzt.
Hinzugefügt in Version 252.
StubPcrKernelParameters
Der PCR-Registerindex, in das die Kernelbefehlszeile und Zugangsberechtigungen eingemessen werden,
formattiert als dezimale ASCII-Zeichenkette (z.B. »12«). Diese Variable ist gesetzt, falls eine
Messung erfolgreich abgeschlossen werden konnte und verbleibt ansonsten nicht gesetzt.
Hinzugefügt in Version 252.
StubPcrInitRDSysExts
Der PCR-Registerindex, in dem sich die Systemd-Erweiterungen für die Initrd, die aus dem Dateisystem
des Kernelabbildes aufgenommen werden, befinden. Formattiert als dezimale ASCII-Zeichenkette (z.B.
»12«). Diese Variable ist gesetzt, falls eine Messung erfolgreich abgeschlossen werden konnte und
verbleibt ansonsten nicht gesetzt.
Hinzugefügt in Version 252.
Beachten Sie, dass einige der obigen Variablen auch durch das Systemstartprogramm gesetzt werden können.
Der Rupmf wird sie nur setzen, falls sie nicht bereits gesetzt sind. Einige dieser Variablen werden durch
die Boot-Loader-Schnittstelle[4] gesetzt.
INITRD-RESSOURCEN
Die folgenden Ressourcen werden als Initrd-CPIO-Archiv an den gestarteten Kernel übergeben und stellen
daher die anfängliche Dateisystem-Hierarchie in der Initrd-Ausführungsumgebung dar:
/
Die Haupt-Initrd aus dem PE-Abschnitt ».initrd« des vereinigten Kernelabbilds.
Hinzugefügt in Version 252.
/.extra/credentials/*.cred
Zugangsberechtigungsdateien (Endung ».cred«), die neben dem vereinigten Kernelabbild abgelegt sind
(wie oben beschrieben), werden in das Verzeichnis /.extra/credentials/ in der
Initrd-Ausführungsumgebung kopiert.
Hinzugefügt in Version 252.
/.extra/global_credentials/*.cred
Ähnlich werden Zugangsberechtigungsdateien im Verzeichnis /loader/credentials/ im Dateisystem, in dem
das vereinigte Kernelabbild abgelegt ist, in das Verzeichnis /.extra/global_credentials/ in der
Initrd-Ausführungsumgebung kopiert.
Hinzugefügt in Version 252.
/.extra/sysext/*.raw
Systemerweiterungsabbilddateien (Endung ».raw«), die neben dem vereinigten Kernelabbild abgelegt sind
(wie oben beschrieben), werden in das Verzeichnis /.extra/sysext/ in der Initrd-Ausführungsumgebung
kopiert.
Hinzugefügt in Version 252.
/.extra/tpm2-pcr-signature.json
Das TPM2-PCR-Signatur-JSON-Objekt, das in dem PE-Abschnitt ».pcrsig« des vereinigten Kernelabbildes
enthalten ist, wird in die Datei /.extra/tpm2-pcr-signature.json in der Initrd-Ausführungsumgebung
kopiert.
Hinzugefügt in Version 252.
/.extra/tpm2-pcr-pkey.pem
Der öffentliche PEM-Schlüssel, der in dem PE-Abschnitt ».pcrpkey« des vereinigten Kernelabbildes
enthalten ist, wird in die Datei /.extra/tpm2-pcr-public-key.pem in der Initrd-Ausführungsumgebung
kopiert.
Hinzugefügt in Version 252.
Beachten Sie, dass sich alle diese Dateien in dem »tmpfs«-Dateisystem befinden, das der Kernel für die
Initrd-Dateihierarchie einrichtet und daher verloren gehen, wenn das System von der
Initrd-Ausführungsumgebung in das Dateisystem des Rechners übergeht. Falls diese Ressourcen über diesen
Übergang hinweg erhalten werden sollen, müssen sie zuerst an einen Ort kopiert werden, der den Übergang
übersteht, beispielsweise durch eine geeignete tmpfiles.d(5)-Zeile. Standardmäßig erfolgt dies für die
TPM2-PCR-Signaturdatei und die Datei des öffentlichen Schlüssels.
SMBIOS-TYP-11-ZEICHENKETTEN
systemd-stub kann zur Verwendung von SMBIOS-TYP-11-ZEICHENKETTEN konfiguriert werden. Anwendbare
Zeichenketten bestehen aus einem Namen, gefolgt von »=«, gefolgt vom Wert. systemd-stub wird die Tabelle
nach einer Zeichenkette mit einem bestimmten Namen durchsuchen, und seinen Wert verwenden, falls der Name
gefunden wird. Die folgenden Zeichenketten werden gelesen:
io.systemd.stub.kernel-cmdline-extra
Falls gesetzt, wird der Wert dieser Zeichenkette zu der Liste der Kernelbefehlszeilenargumente, die
in PCR12 eingemessen und an den Kernel übergeben werden, hinzugefügt.
Hinzugefügt in Version 254.
ZUSAMMENBAU VON KERNELABBILDERN
Um ein startbares vereinigtes Kernelabbild aus verschiedenen Komponenten wie oben beschrieben
zusammenzubauen, verwenden Sie ukify(1).
SIEHE AUCH
systemd-boot(7), systemd.exec(5), systemd-creds(1), systemd-sysext(8), Boot Loader Specification[5], Boot Loader Interface[4], ukify(1), systemd-measure(1), TPM2 PCR Measurements Made by systemd[6]
ANMERKUNGEN
1. SBAT
https://github.com/rhboot/shim/blob/main/SBAT.md
2. UKI-Spezifikation
https://uapi-group.org/specifications/specs/unified_kernel_image/
3. Automatische Systemstartbeurteilung
https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT
4. Boot-Loader-Schnittstelle
https://systemd.io/BOOT_LOADER_INTERFACE
5. Systemladerspezifikation
https://uapi-group.org/specifications/specs/boot_loader_specification
6. TPM2 PCR Measurements Made by systemd
https://systemd.io/TPM2_PCR_MEASUREMENTS
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.