BEZEICHNUNG¶

systemd-stub, sd-stub, linuxx64.efi.stub, linuxia32.efi.stub, linuxaa64.efi.stub - Ein einfacher UEFI-Kernel-Systemstartrumpf

ÜBERSICHT¶

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:

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 nummerische 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:

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

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

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

LoaderFirmwareInfo, LoaderFirmwareType

LoaderImageIdentifier

StubDevicePartUUID, StubImageIdentifier

StubInfo

StubPcrKernelImage

StubPcrKernelParameters

StubPcrInitRDSysExts

StubPcrInitRDConfExts

StubProfile

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:

/

/.extra/credentials/*.cred

/.extra/global_credentials/*.cred

/.extra/sysext/*.sysext.raw

/.extra/confext/*.confext.raw

/.extra/tpm2-pcr-signature.json

/.extra/tpm2-pcr-public-key.pem

/.extra/profile, /.extra/os-release

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

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

2.

SBAT

3.

UKI-Spezifikation

4.

Automatische Systemstartbeurteilung

5.

Boot-Loader-Schnittstelle

6.

Systemladerspezifikation

7.

Von Systemd durchgeführte TPM2-PCR-Messungen

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