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>