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:
parent
cae4ad367d
commit
0155b0657d
@ -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>
|
||||
|
Loading…
Reference in New Issue
Block a user