shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-19 22:50:17 +03:00
Code

man/systemd-stub: reword descriptions of .dtb and .profile sections

Browse Source 
- The text was clearly edited in variuos places to e.g. allow multiple
  sections, so it first said that sections are singletons, and immediately
  after that that some section are not.
- Replace "regardless of the kernel" with "regardless of the kernel version".
  The kernel is very much involved e.g. in loading of the initrds.
- Various other small rewordings to make the text more legible.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2024-10-03 12:52:56 +02:00 committed by Luca Boccassi
parent 33f1c5287f
commit fb0ef5eac0
1 changed files with 19 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
man/systemd-stub.xml
View File

@ -51,9 +51,9 @@
system into the Linux world.</para>
<para>The UEFI boot stub looks for various resources for the kernel invocation inside the UEFI PE binary
itself. This allows combining various resources inside a single PE binary image (usually called "Unified
Kernel Image", or "UKI" for short), which may then be signed via UEFI SecureBoot as a whole, covering all
individual resources at once. Specifically it may include the following PE sections:</para>
itself. This allows combining various resources inside a single PE binary image (a "Unified Kernel Image"
or "UKI" for short), which may then be signed via UEFI SecureBoot as a whole, covering all individual
resources at once. Specifically it may include the following PE sections:</para>
<itemizedlist>
<!-- Let's keep this in the canonical order we also measure the sections by, i.e. as in
@ -96,10 +96,10 @@
signature data in the <literal>.pcrsig</literal> section.</para></listitem>
</itemizedlist>
<para>Generally, the sections above should appear at most once in a UKI. That said, a concept of
"profiles" is defined, that allows multiple sets of these sections to exist in a single UKI file, of
which one can be selected at boot. For this an additional PE section <literal>.profile</literal> is
defined which can be used as separator between multiple sets of these settings. The
<para>In a basic UKI, the sections listed above appear at most once. In a multi-profile UKI,
multiple sets of these sections are present in a single file and form "profiles",
one of which can be selected at boot. For this, the PE section <literal>.profile</literal> is
defined to be used as the separator between sets of sections. The
<literal>.profile</literal> section itself may contain meta-information about the section, and follows a
similar structure as the contents of the <literal>.osrel</literal> section. For further details about
multi-profile UKIs, see below.</para> <para>If UEFI SecureBoot is enabled and the
@ -191,13 +191,14 @@
<listitem><para>Similarly, files
<filename><replaceable>foo</replaceable>.efi.extra.d/*.addon.efi</filename> are loaded and verified as
PE binaries, and a <literal>.cmdline</literal> or <literal>.ucode</literal> section is parsed from them.
Addons are supposed to be used to pass additional kernel command line parameters, or Devicetree blobs,
and microcode updates, regardless of the kernel image being booted, for example to allow platform vendors
to ship platform-specific configuration.</para>
PE binaries and specific sections are loaded from them. Addons are used to pass additional kernel
command line parameters (<literal>.cmdline</literal> section), or Devicetree blobs
(<literal>.dtb</literal> section), and microcode updates (<literal>.ucode</literal> section). Addons
allow those resources to be passed regardless of the kernel version being booted, for example allowing
platform vendors to ship platform-specific configuration.</para>
<para>In case Secure Boot is enabled, these files will be validated using keys in UEFI DB, Shim's DB or
Shim's MOK, and will be rejected otherwise. Additionally, if both the addon and the UKI contain a
Shim's MOK, and only loaded if the check passes. Additionally, if both the addon and the UKI contain a
<literal>.uname</literal> section, the addon will be rejected if they do not match exactly. It is
recommended to always add a <literal>.sbat</literal> section to all signed addons, so that they may be
revoked with a SBAT policy update, without requiring blocklisting via DBX/MOKX. The
@ -222,14 +223,14 @@
<listitem><para>Files <filename>/loader/credentials/*.cred</filename> are packed up in a
<command>cpio</command> archive and placed in the <filename>/.extra/global_credentials/</filename>
directory of the initrd file hierarchy. This is supposed to be used to pass additional credentials to
the initrd, regardless of the kernel being booted. The generated <command>cpio</command> archive is
measured into TPM PCR 12 (if a TPM is present).</para></listitem>
the initrd, regardless of the kernel version being booted. The generated <command>cpio</command>
archive is measured into TPM PCR 12 (if a TPM is present).</para></listitem>
<listitem><para>Additionally, files <filename>/loader/addons/*.addon.efi</filename> are loaded and
verified as PE binaries, and <literal>.cmdline</literal>, <literal>.dtb</literal> and/or
<literal>.ucode</literal>sections are parsed from them. This is supposed to be used to pass additional
command line parameters, Devicetree blobs and microcode updates to the kernel, regardless of the
kernel being booted.</para></listitem>
verified as PE binaries, and <literal>.cmdline</literal>, <literal>.dtb</literal>, and
<literal>.ucode</literal> sections are parsed from them. This is supposed to be used to pass additional
command line parameters, DeviceTree blobs, and microcode updates to the kernel, regardless of the
kernel version being booted.</para></listitem>
</itemizedlist>
<para>These mechanisms may be used to parameterize and extend trusted (i.e. signed), immutable initrd