Merge pull request #27358 from bluca/pe_mule

stub: allow loading and verifying kernel command line addons
This commit is contained in:
Lennart Poettering
2023-05-25 03:56:06 -07:00
committed by GitHub
20 changed files with 421 additions and 39 deletions
+39 -1
View File
@@ -28,8 +28,10 @@
<para><filename>/usr/lib/systemd/boot/efi/linuxx64.efi.stub</filename></para>
<para><filename>/usr/lib/systemd/boot/efi/linuxia32.efi.stub</filename></para>
<para><filename>/usr/lib/systemd/boot/efi/linuxaa64.efi.stub</filename></para>
<para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.addon.efi</filename></para>
<para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.cred</filename></para>
<para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.raw</filename></para>
<para><filename><replaceable>ESP</replaceable>/loader/addons/*.addon.efi</filename></para>
<para><filename><replaceable>ESP</replaceable>/loader/credentials/*.cred</filename></para>
</refsynopsisdiv>
@@ -57,12 +59,18 @@
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file of
the OS the kernel belongs to, in the <literal>.osrel</literal> PE section.</para></listitem>
<listitem><para>Kernel version information, i.e. the output of <command>uname -r</command> for the
kernel included in the UKI, in the <literal>.uname</literal> PE section.</para></listitem>
<listitem><para>The initrd will be loaded from the <literal>.initrd</literal> PE section.
</para></listitem>
<listitem><para>A compiled binary DeviceTree will be looked for in the <literal>.dtb</literal> PE
section.</para></listitem>
<listitem><para>Kernel version information, i.e. the output of <command>uname -r</command> for the
kernel included in the UKI, in the <literal>.uname</literal> PE section.</para></listitem>
<listitem><para>The kernel command line to pass to the invoked kernel will be looked for in the
<literal>.cmdline</literal> PE section.</para></listitem>
@@ -142,11 +150,41 @@
details on system extension images. The generated <command>cpio</command> archive containing these
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
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, 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, 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> are appended next, and
finally UKI-specific addons are appended last. 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>
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>
<listitem><para>Additionally, files <filename>/loader/addons/*.addon.efi</filename> are loaded and
verified as PE binaries, and a <literal>.cmdline</literal> section is parsed from them. This is
supposed to be used to pass additional command line parameters to the kernel, regardless of the kernel
being booted.</para></listitem>
</itemizedlist>
<para>These mechanisms may be used to parameterize and extend trusted (i.e. signed), immutable initrd
@@ -391,7 +429,7 @@
<varlistentry>
<term><varname>io.systemd.stub.kernel-cmdline-extra</varname></term>
<listitem><para>If set, the value of this string is added to the list of kernel command line
arguments that are passed to the kernel.</para></listitem>
arguments that are measured in PCR12 and passed to the kernel.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
+25 -1
View File
@@ -50,6 +50,7 @@
<varname>Splash=</varname>/<option>--splash=</option>,
<varname>PCRPKey=</varname>/<option>--pcrpkey=</option>,
<varname>Uname=</varname>/<option>--uname=</option>,
<varname>SBAT=</varname>/<option>--sbat=</option>,
and <option>--section=</option>
below.</para>
@@ -369,6 +370,27 @@
</varlistentry>
</variablelist>
</refsect2>
<refsect2>
<title>[Addon:<replaceable>NAME</replaceable>] section</title>
<para>Currently, these options only apply when building PE addons.</para>
<variablelist>
<varlistentry>
<term><varname>SBAT=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></varname></term>
<term><option>--sbat=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></option></term>
<listitem><para>SBAT metadata associated with the addon. SBAT policies are useful to revoke whole
groups of addons with a single, static policy update that does not take space in DBX/MOKX. If not
specified manually, a default metadata entry consisting of
<literal>uki.addon.systemd,1,UKI Addon,uki.addon.systemd,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html</literal>
will be used, to ensure it is always possible to revoke addons. For more information on SBAT see
<ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim's documentation.</ulink></para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
<refsect1>
@@ -464,11 +486,13 @@ Phases=enter-initrd:leave-initrd
--secureboot-private-key=sb.key \
--secureboot-certificate=sb.cert \
--cmdline='debug' \
--sbat='sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
uki.addon.author,1,UKI Addon for System,uki.addon.author,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html'
--output=debug.cmdline
</programlisting>
<para>This creates a signed PE binary that contains the additional kernel command line parameter
<literal>debug</literal>.</para>
<literal>debug</literal> with SBAT metadata referring to the owner of the addon.</para>
</example>
</refsect1>