Scroll to navigation

SYSTEMD-STUB(7) systemd-stub SYSTEMD-STUB(7)

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

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

•Die Initrd wird aus dem PE-Abschnitt ».initrd« geladen.

•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«.

•Nach der an den aufgerufenen Kernel zu übergebenen Kernelbefehlszeile wird im PE-Abschnitt ».cmdline« gesucht.

•Nach der vor Aufruf des Kernels anzuzeigenden Systemstartgraphik (im Windows-.BMP-Format) wird im PE-Abschnitt »&.splash« gesucht.

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

BEGLEITDATEIEN

Der UEFI-Systemstartrumpf systemd-stub sammelt automatisch zwei 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. 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 überprüft und ein Abschnitt ».cmdline« wird aus ihnen ausgelesen. 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]. Erweiterungen sind dazu gedacht, um zusätzliche Kernelbefehlszeilenparameter zu übergeben, unabhängig von dem gestarteten Kernelabbild, zum Beispiel um es Plattformlieferanten zu erlauben, plattformspezifische Konfigurationen auszuliefern. Die geladenen Ergänzungsdateien der Befehlszeile 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 werden Optionen von Ergänzungein in /loader/addons/*.addon.efi angehängt und schließlich werden am Ende UKI-spezifische Ergänzungen angehängt. 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 ein Abschnitt ».cmdline« wird aus ihnen ausgelesen. Dies ist dazu gedacht, zusätzliche Befehlszeilenparameter 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).

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 Einstiegspunkt für das vereinigte PE-Programm) 4
Kern-Kernelcode (eingebettet in das vereinigte PE-Programm) 4 + 11
Betriebssystemveröffentlichungsinformationen (eingebettet in das vereinigte PE-Programm) 4 + 11
Haupt-Initrd (eingebettet in das vereinigte PE-Programm) 4 + 9 + 11
Standard-Kernel-Befehlszeile (eingebettet in das vereinigte PE-Programm) 4 + 11
Kernel-Befehlszeile außer Kraft setzen 12
Startbild (eingebettet in das vereinigte PE-Programm) 4 + 11
TPM2-PCR-Signatur-JSON (eingebettet in das vereinigte PE-Programm, synthetisiert in die Initrd) 4 + 9
TPM2-PCR-PEM öffentlicher Schlüssel (eingebettet in das vereinigte PE-Programm, synthetisiert in die Initrd) 4 + 9 + 11
Zugangsberechtigungen (synthetisierte Initrd aus Begleitdateien) 9 + 12
Systemerweiterungen (synthetisierte Initrd aus Begleitdateien) 9 + 13

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.

LoaderFirmwareInfo, LoaderFirmwareType

Kurze Firmware-Informationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten.

LoaderImageIdentifier

Der Pfad zum EFI-Programm, relativ zum Wurzelverzeichnis der EFI-Systempartition. Verwenden Sie bootctl(1), um diese Daten zu betrachten.

StubInfo

Kurze Rumpfinformationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten.

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.

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.

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.

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[2] 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.

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

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

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

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

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

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.

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[3], Boot-Loader-Schnittstelle[2], ukify(1), systemd-measure(1)

ANMERKUNGEN

1.
Shim-Dokumentation
https://github.com/rhboot/shim/blob/main/SBAT.md
2.
Boot-Loader-Schnittstelle
https://systemd.io/BOOT_LOADER_INTERFACE
3.
Systemladerspezifikation
https://uapi-group.org/specifications/specs/boot_loader_specification

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

systemd 254