1
0
mirror of https://github.com/systemd/systemd.git synced 2025-01-10 05:18:17 +03:00

man/systemd-stub: split and simplify a wall'o'text paragraph

This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2023-11-06 15:02:51 +01:00
parent cae4ad367d
commit 0155b0657d

View File

@ -162,30 +162,32 @@
system extension images is measured into TPM PCR 13 (if a TPM is present).</para></listitem>
<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> section is parsed from them.
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 the both the addon and the UKI contain a
a <literal>.uname</literal> section, the addon will be rejected if they do not exactly match. It is
<filename><replaceable>foo</replaceable>.efi.extra.d/*.addon.efi</filename> are loaded and verified as
PE binaries, and a <literal>.cmdline</literal> section is parsed from them. Addons are supposed to be
used to pass additional kernel command line parameters or Devicetree blobs, regardless of the kernel
image being booted, for example to allow 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 the both the addon and the UKI contain a 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
<citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool will
add a SBAT policy by default if none is passed when building addons. For more information on SBAT see
<ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim's documentation</ulink>.
Addons are supposed to be used to pass additional kernel command line parameters or Devicetree blobs,
regardless of the kernel image being booted, for example to allow platform vendors to ship
platform-specific configuration. The loaded command line addon files are sorted, loaded, and measured
into TPM PCR 12 (if a TPM is present) and appended to the kernel command line. UKI command line options
are listed first, then options from addons in <filename>/loader/addons/*.addon.efi</filename>, and
finally UKI-specific addons. Device tree blobs are loaded and measured following the same algorithm.
Addons are always loaded in the same order based on the filename, so that, given the same set of
addons, the same set of measurements can be expected in PCR12. However, note that the filename is not
protected by the PE signature, and as such an attacker with write access to the ESP could potentially
rename these files to change the order in which they are loaded, in a way that could alter the
functionality of the kernel, as some options might be order dependent. If you sign such addons, you
should pay attention to the PCR12 values and make use of an attestation service so that improper use
of your signed addons can be detected and dealt with using one of the aforementioned revocation
mechanisms.</para></listitem>
<citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool will add
a SBAT policy by default if none is passed when building addons. For more information on SBAT see
<ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.</para>
<para>Addon files are sorted, loaded, and measured into TPM PCR 12 (if a TPM is present) and appended
to the kernel command line. UKI command line options are listed first, then options from addons in
<filename>/loader/addons/*.addon.efi</filename>, and finally UKI-specific addons. Device tree blobs are
loaded and measured following the same algorithm. Addons are always loaded in the same order based on
the filename, so that, given the same set of addons, the same set of measurements can be expected in
PCR12. However, note that the filename is not protected by the PE signature, and as such an attacker
with write access to the ESP could potentially rename these files to change the order in which they are
loaded, in a way that could alter the functionality of the kernel, as some options might be
order-dependent. If you sign such addons, you should pay attention to the PCR12 values and make use of
an attestation service so that improper use of your signed addons can be detected and dealt with using
one of the aforementioned revocation mechanisms.</para></listitem>
<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>