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 UBERSICHT /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 ESP/loader/extensions/*.raw ESP/loader/extensions/*.sysext.raw ESP/loader/extensions/*.confext.raw BESCHREIBUNG systemd-stub (gespeichert auf Platte in den architekturabhangigen Dateien linuxx64.efi.stub, linuxia32.efi.stub, linuxaa64.efi.stub) ist ein einfacher UEFI-Systemstartrumpf. Ein UEFI-Systemstartrumpf ist ein Stuck Code, das an ein Linux-Kernel-Programmabbild angehangt wird und in der UEFI-Firmwareumgebung ausgefuhrt wird, bevor in die Linux-Kernelumgebung ubergewechselt wird. Der UEFI-Systemstartrumpf stellt sicher, dass ein Linux-Kernel als regulares UEFI-Programm ausgefuhrt wird. Er ist in der Lage, verschiedene vorbereitende Aktionen durchzufuhren, bevor das System in die Linux-Welt umgeschaltet wird. Der UEFI-Systemstartrumpf schaut innerhalb des UEFI-PE-Programms selbst nach verschiedenen Ressourcen fur den Kernelaufruf. Dies ermoglicht die Kombination verschiedener Ressourcen innerhalb eines einzigen PE-Programmabbilds (ein >>Unified Kernel Image<< (vereinigtes Kernelabbild) oder kurz >>UKI<<), welches dann selbst wieder uber UEFI SecureBoot als ganzes signiert werden kann, und damit alle einzelnen Ressourcen auf einmal abdeckt. Insbesondere kann er die folgenden PE-Abschnitte enthalten: o Ein Abschnitt >>.linux<< mit dem ELF-Linux-Kernelabbild. Dieser Abschnitt ist notwendig. o Ein optionaler Abschnitt >>.osrel<< mit den Betriebssystemveroffentlichungsinformationen, d.h. der Inhalt der Datei os-release(5) des Betriebssystems, zu dem der Kernel gehort. o Ein optionaler Abschnitt >>.cmdline<< mit der an den aufzurufenden Kernel zu ubergebenden Kernelbefehlszeile. o Ein optionaler Abschnitt >>.initrd<< mit der Initrd. o Ein optionaler Abschnitt >>.ucode<< mit einer Mikrocode enthaltenden Initrd, die an den Kernel vor allen anderen Initrd ubergeben werden soll. Die Initrd darf nicht komprimiert sein. o Ein optionaler Abschnitt >>.splash<< mit einem Bild (im Windows-.BMP-Format), das vor dem Aufruf des Kernels auf dem Bildschirm anzuzeigen ist. o Ein optionaler Abschnitt >>.dtb<< mit einem kompilierten binaren DeviceTree. o 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 Durchfuhrung der gleichen Vergleichsprozedur verwandt. Falls ein Treffer gefunden wird, wird dieser Abschnitt >>.dtbauto<< geladen und >>.dtb<< ausser Kraft gesetzt, falls vorhanden. o Null oder mehrere Abschnitte >>.efifw<< fur das Firmware-Abbild. In vieler Hinsicht funktioniert dies so ahnlich wie >>.dtbauto<<-Abschnitte. systemd-stub wird immer den ersten passenden verwenden. Der Vergleich erfolgt, indem zuerst der passendste Eintrag im Abschnitt >>.hwids<< basierend auf den durch SMBIOS bereitgestellten Hardware-Kennungen (siehe unten) ausgewahlt wird. Falls ein geeigneter Eintrag gefunden wird, wird die Zeichenkette >>fwid<< aus diesem Eintrag zum Ausfuhren der Vergleichsprozedur fur Firmware-Blobs in >>.efifw<<-Abschnitten verwandt. Die erste passende Firmware wird geladen. o 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 (gemass der Spezifikation[1]) und wird dann versuchen, eine von ihnen in jeder der Abschnitte >>.hwids<< zu finden. Der erste passende Abschnitt wird verwandt. o Ein optionaler Abschnitt >>.uname<< mit Kernelversionsinformationen, d.h. die Ausgabe von uname -r fur den im Abschnitt >>.linux<< enthaltenen Kernel. o Ein optionaler Abschnitt >>.sbat<< mit SBAT[2]-Widerrufsmetadaten. o Ein optionaler Abschnitt >>.pcrsig<< mit einer Gruppe kryptographischer Signaturen im JSON-Format fur die erwarteten TPM2-PCR-Werte, nachdem dieser Kernel gestartet wurde. Dies ist zur Implementierung von TPM2-Richtlinien nutzlich, die Plattenverschlusselung und ahnliches an Kernel binden, die mit einem bestimmten Schlussel signiert wurden. o Ein optionaler Abschnitt >>.pcrpkey<< mit einem offentlichen Schlussel im PEM-Format, der auf die Signaturdaten im Abschnitt >>.pcrsig<< passt. In einem einfachen UKI erscheinen die oben aufgefuhrten Abschnitte hochstens 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 ausgewahlt werden kann. Dazu ist der PE-Abschnitt >>&.profile<< als Trenner zwischen Gruppen von Abschnitten zur Verwendung definiert. Der Abschnitt >>.profile<< selbst kann Metainformationen uber den Abschnitt selbst enthalten und folgt einer ahnlichen 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 ausgefuhrten Abbild vorhanden ist, werden alle Versuche, die Kernelbefehlszeile durch Ubergabe anderer Aufrufparameter an das EFI-Programm ausser Kraft zu setzen, ignoriert. Um daher die Ausserkraftsetzung 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 uber 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. ystemd-stub wird die Firmware uber das >>EFI_DT_FIXUP_PROTOCOL<< nach hardwarespezifischen Korrekturen fur den DeviceTree befragen. Der Inhalt 11 dieser 12 Abschnitte wird in TPM PCR 11 eingemessen. Wird anderweitig nicht verwandt und daher konnen die Ergebnisse ohne grossen 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 enthalt, werden nur die PE-Abschnitte der ausgewahlten Profile (und der des Basisprofils, falls nicht ausser Kraft gesetzt) eingemessen. Falls nicht Null, wird das ausgewahlte 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 ubergeben, 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 ubergegangen ist. Werkzeuge wie systemd-cryptsetup@.service(8), systemd-cryptenroll(1) und systemd-creds(1) werden diese Dateien unterhalb dieser Pfade automatisch verwenden, um geschutzte Ressourcen (verschlusselte Dateisysteme oder Zugangsberechtigungen) zu entsperren oder Verschlusselungen an gestartete Kernel zu binden. Weitere Details zum UKI-Konzept finden Sie in der UAPI.5-UKI-Spezifikation[3]. BEGLEITDATEIEN Der UEFI-Systemstartrumpf systemd-stub sammelt automatisch drei Arten von zusatzlichen Hilfs-Begleitdateien, die optional in den Erganzungsverzeichnissen auf der gleichen Partition wie das EFI-Programm abgelegt werden, erstellt ein cpio-Initrd-Archiv daraus und ubergibt sie an den Kernel. Konkret: o Fur 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 Zahler zum Zwecke der Automatischen Systemstartbewertung[4] verwendet, wird dieser Zahler 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, zusatzliche, verschlusselte, authentifizierte Zugangsberechtigungen zum Einsatz mit LoadCredentialEncrypted in der UEFI-Systempartition zu speichern. Siehe systemd.exec(5) und systemd-creds(1) fur Details uber verschlusselte Zugangsberechtigungen. Das erstellte cpio wird in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist). o Ahnlich 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 Ubergabe zusatzlicher UKI-spezifischer Systemerweiterungsabbilder an die Initrd gedacht. Siehe systemd-sysext(8) fur Details uber Systemerweiterungsabbilder. Das erstellte cpio, das diese Systemerweiterungsabbilder enthalt, wird in TPM PCR 13 eingemessen (falls ein TPM vorhanden ist). o Ahnlich werden /loader/extensions/*.sysext.raw-Dateien in einem cpio-Archiv gepackt und im Verzeichnis /.extra/global_sysext/ in der Initrd-Dateihierarchie abgelegt. Dies ist zur Ubergabe zusatzlicher globaler Systemerweiterungsabbilder an die Initrd gedacht. Siehe systemd-sysext(8) fur Details uber Systemerweiterungsabbilder. Das erstellte cpio, das diese Systemerweiterungsabbilder enthalt, wird in TPM PCR 13 eingemessen (falls ein TPM vorhanden ist). o Ahnlich 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 Ubergabe zusatzlicher UKI-spezifischer Konfigurationserweiterungsabbilder an die Initrd gedacht. Siehe systemd-confext(8) fur Details uber Konfigurationserweiterungsabbilder. Das erstellte cpio, das diese Konfigurationserweiterungsabbilder enthalt, wird in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist). o Ahnlich werden /loader/extensions/*.confext.raw-Dateien in einem cpio-Archiv gepackt und im Verzeichnis /.extra/global_confext/ in der Initrd-Dateihierarchie abgelegt. Dies ist zur Ubergabe zusatzlicher globaler Konfigurationserweiterungsabbilder an die Initrd gedacht. Siehe systemd-confext(8) fur Details uber Konfigurationserweiterungsabbilder. Das erstellte cpio, das diese Konfigurationserweiterungsabbilder enthalt, wird in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist). o Ahnlich werden Dateien foo.efi.extra.d/*.addon.efi geladen und als PE-Programme verifiziert und bestimmte Abschnitte werden aus ihnen geladen. Erweiterungen werden zur Ubergabe zusatzlicher Kernelbefehlszeilenparameter (Abschnitt >>.cmdline<<) oder DeviceTree-Blobs (Abschnitt >>.dtb<<), zusatzlicher Initrds (Abschnitt >>.initrd<<) und Mikrocode-Aktualisierungen (Abschnitt >>.ucode<<) verwandt. Erweiterungen erlauben die Weitergabe dieser Ressourcen unabhangig von der gestarteten Kernelversion. Plattformlieferanten ermoglicht dies beispielsweise die Auslieferung plattformspezifischer Konfiguration. Falls Secure Boot aktiviert ist, werden diese Dateien mittels der Schlussel in der UEFI DB, Shims DB oder Shims MOK validiert und nur geladen, falls die Uberprufung erfolgreich ist. Falls zusatzlich sowohl die Erweiterung als auch das UKI einen Abschnitt >>.uname<< enthalt, wird die Erweiterung abgelehnt, falls beide nicht exakt ubereinstimmen. Es wird empfohlen, immer einen Abschnitt >>.sbat<< zu allen signierten Erweiterungen hinzuzufugen, so dass sie mit einer SBAT-Richtlinien-Aktualisierung zuruckziehbar sind, ohne Sperrlisten mittels DBX/MOKX zu benotigen. Das Werkzeug ukify(1) wird standardmassig eine SBAT-Richtlinie hinzufugen, falls keine beim Bau der Erweiterungen ubergeben wurde. Zu weiteren Informationen uber SBAT siehe die Dokumentation von Shim[2]. Erganzungsdateien werden sortiert, geladen, in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist) und an die Kernelbefehlszeile angehangt. UKI-Befehlszeilenoptionen werden zuerst aufgelistet, dann Optionen von Erganzungen in /loader/addons/*.addon.efi und schliesslich Ende UKI-spezifische Erganzungen. Devicetree-Binarddateien werden gemass des gleichen Algorithmus geladen und gemessen. Mikrocode-Erganzungen werden an den Kernel in umgekehrter Reihenfolge ubergeben (UKI-spezifische Erweiterungen, globale Erweiterungen, UKI-eingebettete Abschnitte). Dies erfolgt so, da der Mikrocode-Aktualisierungstreiber bei dem ersten passenden Dateinamen stoppt. Erganzungen werden immer in der gleichen Reihenfolge, basierend auf ihrem Dateinamen, geladen, so dass bei der gleichen Gruppe von Erganzungen die gleiche Gruppe von Messungen in PCR12 erwartet werden kann. Beachten Sie allerdings, dass der Dateiname nicht durch die PE-Signatur geschutzt ist. Daher kann ein Angreifer mit Schreibzugriff auf den ESP moglicherweise diese Dateien umbenennen, um die Reihenfolge zu andern, in der sie geladen werden und das auf eine Art, die die Funktionalitat des Kernels andert, da einige Optionen von der Reihenfolge abhangen konnen. Falls Sie solche Erganzungen 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. o /loader/credentials/*.cred-Dateien werden in ein cpio-Archiv gepackt und im Verzeichnis /.extra/global_credentials/ der Initrd-Dateihierarchie abgelegt. Dies ist zur Ubergabe zusatzlicher Zugangsberechtigungen an die Initrd gedacht, unabhangig von der Version des gestarteten Kernels. Das erstellte cpio wird in TPM PCR 12 eingemessen (falls ein TPM vorhanden ist). o Zusatzlich 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, zusatzliche Befehlszeilenparameter, Devicetree-Binardateien, Initrds und Mikrocode-Aktualisierungen an den Kernel weiterzugeben, unabhangig von der gestarteten Kernelversion. Diese Mechanismen konnen zum Parametrisieren und Erweitern vertrauenswurdiger (d.h. signierter), unveranderbarer 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 Entschlusselung/Authentifizierung mittels TPM, wie das uber systemd-creds encrypt -T (siehe systemd-creds(1) fur Details) offengelegt wird; im Falle der Systemerweiterungsabbilder mittels signierter Verity-Abbilder. UKIs MIT MEHREREN PROFILEN In vielen Kontexten ist es nutzlich, den Aufruf eines einzelnen UKIs in mehreren verschiedenen Modi (oder >>Profilen<<) ohne Aufgabe der kryptographischen Integritat, Messungen und so weiter des Systemstartproesses zu erlauben. Beispielsweise konnte ein einzelnes UKI drei unterschiedliche Profile bereitstellen: einen normalen Systemstart, einen der die >>Auf Werkseinstellungen zurucksetzen<<-Option enthalt und einen, der in den Speicherzielmodus startet (wie in systemd-storagetm.service(8)). Jedes Profil wurde die gleichen Abschnitte >>&.linux<< und >>.initrd<< nutzen, hatten aber getrennte Abschnitte >>.cmdline<<. Beispielweise wurden 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<< unterstutzen. Dieser Abschnitt agiert als Trenner zwischen den PE-Abschnitten der einzelnen Profile. PE-Abschnitte >>.profile<< konnen daher mehrfach in einem einzelnen UKI auftauchen und die anderen oben aufgefuhrten PE-Abschnitte konnen 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 vor den ersten >>.profile<< aufgefuhrten Abschnitte werden als >>Basis<<-Profil des UKI betrachtet. Jeder Abschnitt .profile<< fuhrt dann ein neues Profil ein, die beginnend bei Null nummeriert werden. Die PE-Abschnitte, die jedem >>.profile<< folgen, sind fur 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 ausser Kraft, andernfalls werden die Basis-Profil-Abschnitte verwandt. Ein UKI, das kein >>.profile<< enthalt, wird als aquivalent zu einem betrachtet, das nur ein einzelnes >>.profile<< enthalt, als einzelnes Profil >>@0<<. Es folgt ein einfaches Beispiel fur die Abschnitte eines UKI mit mehreren Profilen, inspiriert von dem vorhergenden Aufbau: Tabelle 1. VBeispiel fur UKI mit mehreren Profilen +-----------+-------------+ |Abschnitt | Profil | +-----------+-------------+ |".linux" | Basisprofil | +-----------+ | |".osrel" | | +-----------+ | |".cmdline" | | +-----------+ | |".initrd" | | +-----------+-------------+ |".profile" | Profil @0 | +-----------+-------------+ |".profile" | Profil @1 | +-----------+ | |".cmdline" | | +-----------+-------------+ |".profile" | Profil @2 | +-----------+ | |".cmdline" | | +-----------+-------------+ Die oben aufgefuhrten Abschnitte wurden 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 ausser Kraft (oder fugt welche hinzu), daher folgt ihm sofort ein weiterer Abschnitt >>.profile<<, der dann Abschnitt @1 einleitet. Dieses Profil setzt die Kernelbefehlszeile ausser Kraft. Schliesslich definieren die letzten zwei Abschnitte Abschnitt @2, wobei erneut die Befehlszeile ausser Kraft gesetzt wird. (Beachten Sie, dass in diesem Beispiel das erste >>.cmdline<< auch hinter das erste >>.profile<< mit einem entsprechenden Effekt verschoben werden konnte. Um die Angelegenheit schon erweiterbar zu halten, ist es wahrscheinlich eine gute Idee, die generische Befehlszeile im Basisabschnitt anstatt in Profil 0 zu behalten, falls spater hinzugefugte Profile diesen wiederverwenden mochten.) Das zu startende Profil kann mittels der Befehlszeile des UKI gesteuert werden: Falls das erste Argument mit >>@<< gefolgt von einer positiven dezimalen Ganzahl beginnt, wahlt 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 uber das Profil enthalten. Es folgt einem ahnlichen Format wie >>.osrel<< (d.h. eine Umgebungsvariablen-Zuweisungsblock-artige Liste von Zeichenketten, die durch Zeilenumbruche 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 Systemstartmenueintrag fur dieses Profil auftaucht (z.B. >>TITLE='Werkszustand fur dieses Gerat 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 vollstandige Liste finden Sie weiter oben). Hierzu gehoren 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 zusatzliche Nullen misst, wenn die Grosse im Speicher die Grosse auf Platte uberschreitet. Um zu verhindern, dass dies auftritt, wird empfohlen sicherzustellen, dass die Grosse jedes von systemd-stub gemessenen Abschnitts immer kleiner als oder identisch gross zu der Grosse auf Platte ist. ukify(1) stellt dies automatisch beim Bau von UKIs oder Erganzungen sicher. Beachten Sie auch, dass der Linux-Kernel alle Initrds, die er empfangt, in TPM PCR 9 einmessen wird. Dies bedeutet, dass jede Art von Initrd (des ausgewahlten UKI-Profils) moglicherweise 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 konnen 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 Einstiegspunkt fur | 4 | |das vereinigte PE-Programm) | | +-----------------------------------------------+------------+ |Kern-Kernelcode (eingebettet in das vereinigte | 4 + 11 | |PE-Programm) | | +-----------------------------------------------+------------+ |Betriebssystemveroffentlichungsinformationen | 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 ausser 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 offentlicher Schlussel | 4 + 9 + 11 | |(eingebettet in das vereinigte PE-Programm, | | |synthetisiert in die Initrd) | | +-----------------------------------------------+------------+ |Zugangsberechtigungen (synthetisierte Initrd | 9 + 12 | |aus Begleitdateien) | | +-----------------------------------------------+------------+ |Systemerweiterungen (synthetisierte Initrd aus | 9 + 13 | |Begleitdateien) | | +-----------------------------------------------+------------+ |Konfigurationserweiterungen (synthetisierte | 9 + 12 | |Initrd aus Begleitdateien) | | +-----------------------------------------------+------------+ |Ausgewahltes Profil, ausser wenn Null | 12 | +-----------------------------------------------+------------+ EFI-VARIABLEN Die folgenden EFI-Variablen werden unter der Lieferanten-UUID >>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f<< fur die Kommunikation zwischen dem Systemstartrumpf und dem Betriebssystem definiert, gesetzt und gelesen: LoaderDevicePartUUID Enthalt die Partitions-UUID der Partition, aus der das Systemstartprogramm fur den aktuellen Systemstart heraus gestartet wurde (normalerweise die EFI-Systempartition). Falls bereits durch das Systemstartprogramm gesetzt, wird dies durch systemd-stub nicht verandert. Falls noch nicht gesetzt, wird dies auf die Partitions-UUID der Partition gesetzt, aus der der vereinigte Kernel gestartet wurde, um Systeme zu unterstutzen, 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. Hinzugefugt in Version 224. LoaderFirmwareInfo, LoaderFirmwareType Kurze Firmware-Informationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten. Hinzugefugt in Version 250. LoaderTpm2ActivePcrBanks Hexadezimale Zeichenkettendarstellung einer Bitmaske mit Werten, die durch die TCG-EFI-Protokollspezifikation fur TPM 2.0 als EFI_TCG2_BOOT_HASH_ALG_* definiert sind. Falls keine TPM2-Unterstutzung oder keine aktiven Banke erkannt wurden, wird dies auf 0 gesetzt. Wird durch das Systemstartprogramm gesetzt. Verwenden Sie systemd-analyze(1) zum Betrachten dieser Daten. Hinzugefugt in Version 258. LoaderImageIdentifier Der Dateisystempfad zu dem EFI-Programm des Systemstartladers fur 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 unterstutzen, die direkt in ein vereinigtes Kernelabbild starten und das Systemstartprogramm umgehen. Verwenden Sie bootctl(1) zur Anzeige dieser Daten. Hinzugefugt in Version 237. StubDevicePartUUID, StubImageIdentifier Ahnlich zu LoaderDevicePartUUID und LoaderImageIdentifier, zeigt aber den Ort des EFI-Programms des vereinigten Kernelabbildes anstelle des Orts des Systemstartladerprogramms an, unabhangig davon, ob ein Systemstartlader verwandt wurde. Hinzugefugt in Version 257. StubDeviceURL Falls das Kernelabbild uber Netzwerksystemstart aufgerufen wurde, enthalt diese Variable die Quell-URL. Dies kann zum automatischen Erlangen zusatzlicher Ressourcen aus der gleichen Quelle verwandt werden. Hinzugefugt in Version 258. StubInfo Kurze Rumpfinformationen. Verwenden Sie bootctl(1), um diese Daten zu betrachten. Hinzugefugt 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. Hinzugefugt 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. Hinzugefugt in Version 252. StubPcrInitRDSysExts Der PCR-Registerindex, in dem sich die Systemerweiterungen fur 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. Hinzugefugt in Version 252. StubPcrInitRDConfExts Der PCR-Registerindex, in dem sich die Konfigurationserweiterungen fur 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. Hinzugefugt in Version 255. StubProfile Der numerische Index des ausgewahlten Profils, ohne das >>@<<, als dezimale Zeichenkette formatiert. Wird fur UKIs mit einem einzelnen und auch mehreren Profilen gesetzt. (Im ersteren Fall wird diese Variable bedingungslos auf >>0<< gesetzt.) Hinzugefugt in Version 257. Beachten Sie, dass einige der obigen Variablen auch durch das Systemstartprogramm gesetzt werden konnen. Der Rupmf wird sie nur setzen, falls sie nicht bereits gesetzt sind. Einige dieser Variablen werden durch die Systemstartlader-Schnittstelle[5] gesetzt. INITRD-RESSOURCEN Die folgenden Ressourcen werden als Initrd-CPIO-Archiv an den gestarteten Kernel ubergeben und stellen daher die anfangliche Dateisystem-Hierarchie in der Initrd-Ausfuhrungsumgebung dar: / Die Haupt-Initrd aus dem PE-Abschnitt >>.initrd<< des vereinigten Kernelabbilds. Hinzugefugt 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-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 252. /.extra/global_credentials/*.cred Ahnlich werden Zugangsberechtigungsdateien im Verzeichnis /loader/credentials/ im Dateisystem, in dem das vereinigte Kernelabbild abgelegt ist, in das Verzeichnis /.extra/global_credentials/ in der Initrd-Ausfuhrungsumgebung kopiert. Hinzugefugt 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-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 252. /.extra/global_sysext/*.sysext.raw Ahnlich werden Systemerweiterungsabbilddateien (Endung >>.sysext.raw<<), die sich im Verzeichnis /loader/extensions/, in dem Dateisystem in dem das vereinigten Kernelabbild liegt, befinden in das Verzeichnis /.extra/global_sysext/ in der Initrd-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 258. /.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-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 255. /.extra/global_confext/*.confext.raw Ahnlich werden Konfigurationserweiterungsabbilddateien (Endung >>.confext.raw<<), die sich im Verzeichnis /loader/extensions/, in dem Dateisystem in dem das vereinigten Kernelabbild liegt, befinden in das Verzeichnis /.extra/global_confext/ in der Initrd-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 258. /.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-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 252. /.extra/tpm2-pcr-public-key.pem Der offentliche PEM-Schlussel, der in dem PE-Abschnitt >>.pcrpkey<< des vereinigten Kernelabbildes enthalten ist, wird in die Datei /.extra/tpm2-pcr-public-key.pem in der Initrd-Ausfuhrungsumgebung kopiert. Hinzugefugt in Version 252. /.extra/profile, /.extra/os-release Die Inhalte der Abschnitte >>.profile<< und >>.osrel<< des ausgewahlten Profils, falls vorhanden. Hinzugefugt in Version 257. Beachten Sie, dass sich alle diese Dateien in dem >>tmpfs<<-Dateisystem befinden, das der Kernel fur die Initrd-Dateihierarchie einrichtet und daher verloren gehen, wenn das System von der Initrd-Ausfuhrungsumgebung in das Dateisystem des Rechners ubergeht. Falls diese Ressourcen uber diesen Ubergang hinweg erhalten werden sollen, mussen sie zuerst an einen Ort kopiert werden, der den Ubergang ubersteht, beispielsweise durch eine geeignete tmpfiles.d(5)-Zeile. Standardmassig erfolgt dies fur die TPM2-PCR-Signaturdatei und die Datei des offentlichen Schlussels. 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 lauft, 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 ubergeben werden, hinzugefugt. Hinzugefugt in Version 254. io.systemd.boot.loglevel Falls gesetzt wird der Wert dieser Zeichenkette als Protokollierstufe verwandt. Gultige Werte (vom kritischten bis zum unkritischten) sind >>emerg<<, >>alert<<, >>crit<<, >>err<<, >>warning<<, >>notice<<, >>info<< und >>debug<<. Hinzugefugt in Version 261. 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), UAPI.1-Systemstartladerspezifikation[6], Systemstartlader-Schnittstelle[5], ukify(1), systemd-measure(1), Von Systemd durchgefuhrte 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. UAPI.5-UKI-Spezifikation https://uapi-group.org/specifications/specs/unified_kernel_image/ 4. Automatische Systemstartbeurteilung https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT 5. Systemstartlader-Schnittstelle https://systemd.io/BOOT_LOADER_INTERFACE 6. UAPI.1-Systemstartladerspezifikation https://uapi-group.org/specifications/specs/boot_loader_specification 7. Von Systemd durchgefuhrte TPM2-PCR-Messungen https://systemd.io/TPM2_PCR_MEASUREMENTS UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.2 SYSTEMD-STUB(7)