Provided by: manpages-de_4.21.0-2_all bug

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
       ┌─────────────────────────────────────────────┬────────────┐
       │BetriebssystemressourceMess-PCR   │
       ├─────────────────────────────────────────────┼────────────┤
       │Code von systemd-stub (der                   │ 4          │
       │Einstiegspunkt für das                       │            │
       │vereinigte PE-Programm)                      │            │
       ├─────────────────────────────────────────────┼────────────┤
       │Kern-Kernelcode (eingebettet in              │ 4 + 11     │
       │das 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⟩.