Provided by: manpages-de_4.27.0-1_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/…/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 (ein »Unified Kernel Image« (vereinigtes Kernelabbild) oder kurz »UKI«), welches dann
selbst wieder über UEFI SecureBoot als ganzes signiert werden kann, und damit alle einzelnen Ressourcen
auf einmal abdeckt. Insbesondere kann er die folgenden PE-Abschnitte enthalten:
• Ein Abschnitt ».linux« mit dem ELF-Linux-Kernelabbild. Dieser Abschnitt ist notwendig.
• Ein optionaler Abschnitt ».osrel« mit den Betriebssystemveröffentlichungsinformationen, d.h. der
Inhalt der Datei os-release(5) des Betriebssystems, zu dem der Kernel gehört.
• Ein optionaler Abschnitt ».cmdline« mit der an den aufzurufenden Kernel zu übergebenden
Kernelbefehlszeile.
• Ein optionaler Abschnitt ».initrd« mit der Initrd.
• Ein optionaler Abschnitt ».ucode« mit einer Mikrocode enthaltenden Initrd, die an den Kernel vor
allen anderen Initrd übergeben werden soll. Die Initrd darf nicht komprimiert sein.
• Ein optionaler Abschnitt ».splash« mit einem Bild (im Windows-.BMP-Format), das vor dem Aufruf des
Kernels auf dem Bildschirm anzuzeigen ist.
• Ein optionaler Abschnitt ».dtb« mit einem kompilierten binären DeviceTree.
• Null oder mehr Abschnitte ».dtbauto«. systemd-stub wird immer versuchen, den ersten passenden zu
verwenden. Der Abgleich erfolgt durch Nehmen der ersten mit dem DeviceTree kompatiblen Zeichenkette,
die durch die Firmware in Konfigurationstabellen bereitgestellt wird, und dem Vergleichen mit der
ersten kompatiblen Zeichenkette von jeder der Abschnitte ».dtbauto«. Falls die Firmware keinen
DeviceTree bereitstellt, erfolgt der Vergleich stattdessen mittels des Abschnitts .hwids. Nach
Auswahl eines Abschnitts ».hwids« (siehe die nachfolgende Beschreibung), wird die kompatible
Zeichenkette aus diesem Abschnitt zur Durchführung der gleichen Vergleichsprozedur verwandt. Falls
ein Treffer gefunden wird, wird dieser Abschnitt ».dtbauto« geladen und .dtb außer Kraft gesetzt,
falls vorhanden.
• Null oder mehrere Abschnitte ».hwids« mit Hardware-Kennungen der Maschinen, mit denen DeviceTrees
verglichen werden sollen. systemd-stub wird die SMBIOS-Daten verwenden, um die Hardware-Kennungen der
Maschine zu berechnen (gemäß der Spezifikation[1]) und wird dann versuchen, eine von ihnen in jeder
der Abschnitte ».hwids« zu finden. Der erste passende Abschnitt wird verwandt.
• Ein optionaler Abschnitt ».uname« mit Kernelversionsinformationen, d.h. die Ausgabe von uname -r für
den im Abschnitt ».linux« enthaltenen Kernel.
• Ein optionaler Abschnitt ».sbat« mit SBAT[2]-Widerrufsmetadaten.
• Ein optionaler 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 optionaler Abschnitt ».pcrpkey« mit einem öffentlichen Schlüssel im PEM-Format, der auf die
Signaturdaten im Abschnitt ».pcrsig« passt.
In einem einfachen UKI erscheinen die oben aufgeführten Abschnitte höchstens einmal, mit der Ausnahme der
Abschnitte ».dtbauto« und ».hwids«. In einem UKI mit mehreren Profilen sind mehrere Gruppen dieser
Abschnitte in einer einzigen Datei vorhanden und bilden »Profile«, von denen eines beim Systemstart
ausgewählt werden kann. Dazu ist der PE-Abschnitt »&.profile« als Trenner zwischen Gruppen von
Abschnitten zur Verwendung definiert. Der Abschnitt ».profile« selbst kann Metainformationen über den
Abschnitt selbst enthalten und folgt einer ähnlichen Struktur wie die Inhalte des Abschnitts ».osrel«.
Weitere Details zu UKIs mit mehreren Profilen finden Sie weiter unten.
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 11 dieser 12 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. Falls ein UKI mehrere Profile enthält, werden nur
die PE-Abschnitte der ausgewählten Profile (und der des Basisprofils, falls nicht außer Kraft gesetzt)
eingemessen.
Falls nicht Null, wird das ausgewählte numerische Profil in PCR 12 eingemessen.
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[3].
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[4] 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 Konfigurationserweiterungsabbilder
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
bestimmte Abschnitte werden aus ihnen geladen. Erweiterungen werden zur Übergabe zusätzlicher
Kernelbefehlszeilenparameter (Abschnitt ».cmdline«) oder DeviceTree-Blobs (Abschnitt ».dtb«),
zusätzlicher Initrds (Abschnitt ».initrd«) und Mikrocode-Aktualisierungen (Abschnitt ».ucode«)
verwandt. Erweiterungen erlauben die Weitergabe dieser Ressourcen unabhängig von der gestarteten
Kernelversion. Plattformlieferanten ermöglicht dies beispielsweise die Auslieferung
plattformspezifischer Konfiguration.
Falls Secure Boot aktiviert ist, werden diese Dateien mittels der Schlüssel in der UEFI DB, Shims DB
oder Shims MOK validiert und nur geladen, falls die Überprüfung erfolgreich ist. 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[2].
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.
Mikrocode-Ergänzungen werden an den Kernel in umgekehrter Reihenfolge übergeben (UKI-spezifische
Erweiterungen, globale Erweiterungen, UKI-eingebettete Abschnitte). Dies erfolgt so, da der
Mikrocode-Aktualisierungstreiber bei dem ersten passenden Dateinamen stoppt. 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 der Version des gestarteten Kernels. 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«, ».dtb«, ».initrd« und ».ucode« werden aus ihnen ausgewertet. Dies ist dazu
gedacht, zusätzliche Befehlszeilenparameter, Devicetree-Binärdateien, Initrds und
Mikrocode-Aktualisierungen an den Kernel weiterzugeben, unabhängig von der gestarteten Kernelversion.
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.
UKIs MIT MEHREREN PROFILEN
In vielen Kontexten ist es nützlich, den Aufruf eines einzelnen UKIs in mehreren verschiedenen Modi (oder
»Profilen«) ohne Aufgabe der kryptographischen Integrität, Messungen und so weiter des
Systemstartproesses zu erlauben. Beispielsweise könnte ein einzelnes UKI drei unterschiedliche Profile
bereitstellen: einen normalen Systemstart, einen der die »Auf Werkseinstellungen zurücksetzen«-Option
enthält und einen, der in den Speicherzielmodus startet (wie in systemd-storagetm.service(8)). Jedes
Profil würde die gleichen Abschnitte »&.linux« und ».initrd« nutzen, hätten aber getrennte Abschnitte
».cmdline«. Beispielweise würden die letzteren beiden Profile die normale Kernelbefehlszeile um
»systemd.unit=factory-reset.target« oder »rd.systemd.unit=storagetm.target« erweitern.
Ein einzelnes UKI kann mehrere Profile mittels des besonderen PE-Abschnitts ».profile« unterstützen.
Dieser Abschnitt agiert als Trenner zwischen den PE-Abschnitten der einzelnen Profile. PE-Abschnitte
».profile« können daher mehrfach in einem einzelnen UKI auftauchen und die anderen oben aufgeführten
PE-Abschnitte können auch mehrfach auftauchen, falls ».profile« verwandt wird, aber nur einmal vor dem
ersten Abschnitt ».profile«, einmal zwischen jedem nachfolgendem Paar und einmal nach dem letzten
Auftreten von ».profile«. Die für den ersten ».profile« aufgeführten Abschnitte werden als »Basis«-Profil
des UKI betrachtet. Jeder Abschnitt .profile« führt dann ein neues Profil ein, die beginnend bei Null
nummeriert werden. Die PE-Abschnitte, die jedem ».profile« folgen, sind für dieses Profil bestimmt. Wenn
der Systemstart in ein bestimmtes Profil erfolgt, werden die Profile des Basisabschnitts zusammen mit den
Abschnitten des bestimmten Profils verwandt: Falls der gleiche Abschnitt in beiden definiert ist, setzt
der profilbezogene Abschnitt die Version des Basisprofils außer Kraft, andernfalls werden die
profilbezogenen Abschnitte zusammen mit den Abschnitten des Basisprofils verwandt.
Ein UKI, das kein ».profile« enthält, wird als äquivalent zu einem betrachtet, das nur ein einzelnes
».profile« enthält, als einzelnes Profil @0.
Es folgt ein einfaches Beispiel für die Abschnitte eines UKI mit mehreren Profilen, inspiriert von dem
vorhergenden Aufbau:
Tabelle 1. VBeispiel für UKI mit mehreren Profilen
┌────────────┬─────────────┐
│ Abschnitt │ Profil │
├────────────┼─────────────┤
│ ".linux" │ │
├────────────┤ │
│ ".osrel" │ │
├────────────┤ Basisprofil │
│ ".cmdline" │ │
├────────────┤ │
│ ".initrd" │ │
├────────────┼─────────────┤
│ ".profile" │ Profil @0 │
├────────────┼─────────────┤
│ ".profile" │ │
├────────────┤ Profil @1 │
│ ".cmdline" │ │
├────────────┼─────────────┤
│ ".profile" │ │
├────────────┤ Profil @2 │
│ ".cmdline" │ │
└────────────┴─────────────┘
Die oben aufgeführten Abschnitte würden drei Profile definieren. Die ersten vier Abschnitte erstellen das
Basisprofil. Ein Abschnitt ».profile« leitet dann das Profil @0 ein. Es setzt keine Abschnitte des
Basisprofils außer Kraft (oder fügt welche hinzu), daher folgt ihm sofort ein weiterer Abschnitt
».profile«, der dann Abschnitt @1 einleitet. Dieses Profil setzt die Kernelbefehlszeile außer Kraft.
Schließlich definieren die letzten zwei Abschnitte Abschnitt @2, wobei erneut die Befehlszeile außer
Kraft gesetzt wird. (Beachten Sie, dass in diesem Beispiel das erste ».cmdline« auch hinter das erste
».profile« mit einem entsprechenden Effekt verschoben werden könnte. Um die Angelegenheit schön
erweiterbar zu halten, ist es wahrscheinlich eine gute Idee, die generische Befehlszeile im
Basisabschnitt anstatt in Profil 0 zu behalten, falls später hinzugefügte Profile diesen wiederverwenden
möchten.)
Das zu startende Profil kann mittels der Befehlszeile des UKI gesteuert werden: Falls das erste Argument
mit »@« gefolgt von einer positiven dezimalen Ganzahl beginnt, wählt es das zu startende Profil aus.
Falls das erste Argument nicht auf diese Weise festgelegt ist, dann wird das UKI automatisch Profil 0
starten.
Ein ».profile«-Abschnitt kann Metainformationen über das Profil enthalten. Es folgt einem ähnlichen
Format wie ».osrel« (d.h. eine Umgebungsvariablen-Zuweisungsblock-artige Liste von Zeichenketten, die
durch Zeilenumbrüche getrennt sind). Derzeit sind zwei Felder definiert: »ID=« ist dazu gedacht, eine
kurze kennzeichnende Zeichenkette zu tragen, die das Profil identifiziert (z.B. »ID=Werkszustand«).
»TITLE=« sollte eine menschenlesbare Zeichenkette enthalten, die im Systemstartmenüeintrag für dieses
Profil auftaucht (z.B. »TITLE='Werkszustand für dieses Gerät wiederherstellen').
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). Hierzu gehören alle UKI-Profile.
Beachten Sie auch, dass systemd-stub beim Messen eines PE-Abschnittes die Anzahl an Byte misst, die der
Abschnitt im Arbeitsspeicher belegt (VirtualSize) und nicht die Anzahl an Byte, die der Abschnitt auf
Platte belegt (SizeOfRawData). Das bedeutet, dass systemd-stub letztendlich zusätzliche Nullen misst,
wenn die Größe im Speicher die Größe auf Platte überschreitet. Um zu verhindern, dass dies auftritt, wird
empfohlen sicherzustellen, dass die Größe jedes von systemd-stub gemessenen Abschnitts immer kleiner als
oder identisch groß zu der Größe auf Platte ist. ukify(1) stellt dies automatisch beim Bau von UKIs oder
Ergänzungen sicher.
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 (des ausgewählten UKI-Profils) möglicherweise zwei oder drei Mal
gemessen wird: die im Kernel-Abbild eingebetteten Initrds werden in PCR 4, PCR 9 und PCR 11 eingemessen;
die aus den Zugangsberechtigungen synthetisierte Initrd (und die aus den Konfigurationserweiterungen
synthetisierte) 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 2. 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) │ │
├──────────────────────────────────────────────┼────────────┤
│ Microcode-Initrd (eingebettet in das │ 4 + 9 + 11 │
│ vereinigte 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) │ │
├──────────────────────────────────────────────┼────────────┤
│ Konfigurationserweiterungen (synthetisierte │ 9 + 12 │
│ Initrd aus Begleitdateien) │ │
├──────────────────────────────────────────────┼────────────┤
│ Ausgewähltes Profil, außer wenn Null │ 12 │
└──────────────────────────────────────────────┴────────────┘
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 Partition, aus der das Systemstartprogramm für den aktuellen
Systemstart heraus gestartet wurde (normalerweise die EFI-Systempartition). Falls bereits durch das
Systemstartprogramm gesetzt, wird dies durch systemd-stub nicht verändert. Falls noch nicht gesetzt,
wird dies auf die Partitions-UUID der Partition gesetzt, aus der der vereinigte Kernel gestartet
wurde, um Systeme zu unterstützen, die direkt in ein vereinigtes Kernelabbild starten und das
Systemstartprogramm umgehen. systemd-gpt-auto-generator(8) verwendet diese Informationen, um
automatisch die Platte zu finden, aus der gestartet wurde, um verschiedene andere Partitionen auf der
gleichen Platte automatisch zu erkennen.
Hinzugefügt in Version 224.
LoaderFirmwareInfo, LoaderFirmwareType
Kurze Firmware-Informationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten.
Hinzugefügt in Version 250.
LoaderImageIdentifier
Der Dateisystempfad zu dem EFI-Programm des Systemstartladers für den aktuellen Systemstart, relativ
zum Wurzelverzeichnis der Partition (d.h. relativ zu der Partition, die durch LoaderDevicePartUUID
angezeigt wird, siehe oben). Falls nicht gesetzt wird dies auf den Dateisystempfad des EFI-Programms
des gestarteten vereinigten Kernels gesetzt, um Systeme zu unterstützen, die direkt in ein
vereinigtes Kernelabbild starten und das Systemstartprogramm umgehen. Verwenden Sie bootctl(1) zur
Anzeige dieser Daten.
Hinzugefügt in Version 237.
StubDevicePartUUID, StubImageIdentifier
Ähnlich zu LoaderDevicePartUUID und StubImageIdentifier, zeigt aber den Ort des EFI-Programms des
vereinigten Kernelabbildes anstelle des Orts des Systemstartladerprogramms an, unabhängig davon, ob
ein Systemstartlader verwandt wurde.
Hinzugefügt in Version 257.
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.
StubProfile
Der numerische Index des ausgewählten Profils, ohne das »@«, als dezimale Zeichenkette formatiert.
Wird für UKIs mit einem einzelnen und auch mehreren Profilen gesetzt. (Im ersteren Fall wird diese
Variable bedingungslos auf »0« gesetzt.)
Hinzugefügt in Version 257.
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[5] 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-public-key.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.
/.extra/profile, /.extra/os-release
Die Inhalte der Abschnitte ».profile« und ».osrel« des ausgewählten Profils, falls vorhanden.
Hinzugefügt in Version 257.
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. Sofern systemd-stub nicht
erkennt, dass es innerhalb einer vertraulichen Verarbeitungsumgebung läuft, wird es 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), Systemladerspezifikation[6],
Boot-Loader-Schnittstelle[5], ukify(1), systemd-measure(1), Von Systemd durchgeführte
TPM2-PCR-Messungen[7]
ANMERKUNGEN
1. Spezifikation
https://learn.microsoft.com/de-de/windows-hardware/drivers/install/specifying-hardware-ids-for-a-computer
2. SBAT
https://github.com/rhboot/shim/blob/main/SBAT.md
3. UKI-Spezifikation
https://uapi-group.org/specifications/specs/unified_kernel_image/
4. Automatische Systemstartbeurteilung
https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT
5. Boot-Loader-Schnittstelle
https://systemd.io/BOOT_LOADER_INTERFACE
6. Systemladerspezifikation
https://uapi-group.org/specifications/specs/boot_loader_specification
7. 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 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.
systemd 257.6 SYSTEMD-STUB(7)