oracular (7) systemd-stub.7.gz

Provided by: manpages-de_4.23.1-1_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/…/foo.efi.extra.d/*.sysext.raw
           ESP/…/foo.efi.extra.d/*.confext.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:

       •   Ein Abschnitt ».linux« mit dem ELF-Linux-Kernelabbild.

       •   Ein Abschnitt ».osrel« mit den Betriebssystemveröffentlichungsinformationen, d.h. der Inhalt der
           Datei os-release(5) des Betriebssystems, zu dem der Kernel gehört.

       •   Ein Abschnitt ».cmdline« mit der an den aufzurufenden Kernel zu übergebenden Kernelbefehlszeile.

       •   Ein Abschnitt ».initrd« mit der Initrd.

       •   A ".ucode" section with an initrd containing microcode, to be handed to the kernel before any other
           initrd. This initrd must not be compressed.

       •   Ein Abschnitt ».splash« mit einem Bild (im Windows-.BMP-Format), das vor dem Aufruf des Kernels auf
           dem Bildschirm anzuzeigen ist.

       •   Ein Abschnitt ».dtb« mit einem kompilierten binären DeviceTree.

       •   Ein Abschnitt ».uname« mit Kernelversionsinformationen, d.h. die Ausgabe von uname -r für den im
           Abschnitt ».linux« enthaltenen Kernel.

       •   Ein Abschnitt ».sbat« mit SBAT[1]-Widerrufsmetadaten.

       •   Ein Abschnitt ».pcrsig« mit einer Gruppe kryptographischer Signaturen im JSON-Format für die
           erwarteten TPM2-PCR-Werte, nachdem dieser Kernel gestartet wurde. 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 Abschnitt ».pcrpkey« mit einem öffentlichen Schlüssel im PEM-Format, der auf die Signaturdaten im
           Abschnitt ».pcrsig« 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 acht dieser neun Abschnitte wird in TPM PCR 11 eingemessen. Wird anderweitig nicht verwandt
       und daher können die Ergebnisse ohne großen Aufwand vorberechnet werden. Der Abschnitt »&.pcrsig« wird in
       diese Messung nicht eingeschlossen, da er dazu gedacht ist, die Signaturen der Ausgabe des Messaktion zu
       enthalten und kann daher nicht auch deren Eingabe sein.

       Wenn ».pcrsig«- und/oder ».pcrpkey«-Abschnitte 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.

       Weitere Details zum UKI-Konzept finden Sie in der UKI-Spezifikation[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/*.sysext.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 foo.efi.extra.d/*.confext.raw-Dateien in einem cpio-Archiv gepackt und im Verzeichnis
           /.extra/confext/ in der Initrd-Dateihierarchie abgelegt. Dies ist zur Übergabe zusätzlicher
           Konfigurationserweiterungsabbilder an die Initrd gedacht. Siehe systemd-confext(8) für Details über
           Konfigurationserweiterungsabbilder. Das erstellte cpio, das diese Systemerweiterungsabbilder enthält,
           wird in TPM PCR 12 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.

           Falls Secure Boot aktiviert ist, werden diese Dateien mittels der Schlüssel in der UEFI DB, Shims DB
           oder Shims MOK validiert und andernfalls abgelehnt. Falls zusätzlich sowohl die Erweiterung als auch
           das UKI einen Abschnitt ».uname« enthält, wird die Erweiterung abgelehnt, falls beide nicht exakt
           übereinstimmen. Es wird empfohlen, immer einen Abschnitt ».sbat« zu allen signierten Erweiterungen
           hinzuzufügen, so dass sie mit einer SBAT-Richtlinien-Aktualisierung zurückziehbar sind, ohne
           Sperrlisten mittels DBX/MOKX zu benötigen. Das Werkzeug ukify(1) wird standardmäßig eine
           SBAT-Richtlinie hinzufügen, falls keine beim Bau der Erweiterungen übergeben wurde. Zu weiteren
           Informationen über SBAT siehe die Dokumentation von Shim[1].

           Ergänzungsdateien werden sortiert, geladen, in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist)
           und an die Kernelbefehlszeile angehängt. UKI-Befehlszeilenoptionen werden zuerst aufgelistet, dann
           Optionen von Ergänzungen in /loader/addons/*.addon.efi und schließlich Ende UKI-spezifische
           Ergänzungen. Devicetree-Binärddateien werden gemäß des gleichen Algorithmus geladen und gemessen.
           Ergänzungen werden immer in der gleichen Reihenfolge, basierend auf ihrem Dateinamen, geladen, so
           dass bei der gleichen Gruppe von Ergänzungen die gleiche Gruppe von Messungen in PCR12 erwartet
           werden kann. Beachten Sie allerdings, dass der Dateiname nicht durch die PE-Signatur geschützt ist.
           Daher kann ein Angreifer mit Schreibzugriff auf den ESP möglicherweise diese Dateien umbenennen, um
           die Reihenfolge zu ändern, in der sie geladen werden und das auf eine Art, die die Funktionalität des
           Kernels ändert, da einige Optionen von der Reihenfolge abhängen können. Falls Sie solche Ergänzungen
           signieren, sollten Sie auf die PCR12-Werte achten und einen Bescheinigungs-Dienst verwenden, so dass
           die inkorrekte Verwendung von ihren signierten Erweiterungen erkannt werden kann und eine der
           vorstehenden Widerruf-Mechanismen darauf angewandt werden kann.

       •   /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).

       •   Zusätzlich werden Dateien /loader/addons/*.addon.efi geladen und als PE-Programme verifiziert und
           Abschnitte ».cmdline« und/oder ».dtb« werden aus ihnen ausgelesen. Dies ist dazu gedacht, zusätzliche
           Befehlszeilenparameter oder Devicetree-Binärdateien an den Kernel weiterzugeben, unabhängig vom
           gestarteten Kernel.

       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).

       Also note that the Linux kernel will measure all initrds it receives into TPM PCR 9. This means every
       type of initrd will be measured two or three times: the initrds embedded in the kernel image will be
       measured to PCR 4, PCR 9 and PCR 11; the initrd synthesized from credentials (and the one synthesized
       from configuration extensions) will be measured to both PCR 9 and PCR 12; the initrd synthesized from
       system extensions will be measured to both PCR 4 and PCR 9. Let's summarize the OS resources and the PCRs
       they are measured to:

       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 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)                                 │            │
       ├─────────────────────────────────────────────┼────────────┤
       │Microcode initrd (embedded in unified PE     │ 4 + 9 + 11 │
       │binary)                                      │            │
       ├─────────────────────────────────────────────┼────────────┤
       │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)                          │            │
       ├─────────────────────────────────────────────┼────────────┤
       │Konfigurationserweiterungen (synthetisierte  │ 9 + 12     │
       │Initrd 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 Systemerweiterungen für die Initrd, die aus dem Dateisystem
           des Kernelabbildes aufgenommen werden, befinden. Formattiert als dezimale ASCII-Zeichenkette (z.B.
           »13«). Diese Variable ist gesetzt, falls eine Messung erfolgreich abgeschlossen werden konnte und
           verbleibt ansonsten nicht gesetzt.

           Hinzugefügt in Version 252.

       StubPcrInitRDConfExts
           Der PCR-Registerindex, in dem sich die Konfigurationserweiterungen 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 255.

       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/*.sysext.raw
           Systemerweiterungsabbilddateien (Endung ».sysext.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/confext/*.confext.raw
           Konfigurationserweiterungsabbilddateien (Endung ».confext.raw«), die neben dem vereinigten
           Kernelabbild abgelegt sind (wie oben beschrieben), werden in das Verzeichnis /.extra/confext/ in der
           Initrd-Ausführungsumgebung kopiert.

           Hinzugefügt in Version 255.

       /.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 can be configured using SMBIOS Type 11 strings. Applicable strings consist of a name,
       followed by "=", followed by the value. Unless systemd-stub detects it is running inside a confidential
       computing environment, systemd-stub will search the table for a string with a specific name, and if
       found, use its value. The following strings are read:

       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), Systemladerspezifikation[5],
       Boot-Loader-Schnittstelle[4], ukify(1), systemd-measure(1), Von Systemd durchgeführte
       TPM2-PCR-Messungen[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. Von Systemd durchgeführte TPM2-PCR-Messungen
           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⟩.