summaryrefslogtreecommitdiff
path: root/man/loader.conf.xml
diff options
context:
space:
mode:
authorVincent Dagonneau <v@vda.io>2022-05-09 14:13:28 -0400
committerLennart Poettering <lennart@poettering.net>2022-08-03 10:11:08 +0200
commite6b0cfad514f44d9b77380793b02302772a98654 (patch)
tree332444d7b0edbaf8534311bb5e232aa5bd617ea7 /man/loader.conf.xml
parent9e6e3379ba9a68e6d4bcb12c0d6742d0dee64b00 (diff)
downloadsystemd-e6b0cfad514f44d9b77380793b02302772a98654.tar.gz
This patch adds support for enrolling secure boot boot keys from sd-boot.
***DANGER*** NOTE ***DANGER*** This feature might result in your device becoming soft-brick as outlined below, please use this feature carefully. ***DANGER*** NOTE ***DANGER*** If secure-boot-enrollment is set to no, then no action whatsoever is performed, no matter the files on the ESP. If secure boot keys are found under $ESP/loader/keys and secure-boot-enrollment is set to either manual or force then sd-boot will generate enrollment entries named after the directories they are in. The entries are shown at the very bottom of the list and can be selected by the user from the menu. If the user selects it, the user is shown a screen allowing for cancellation before a timeout. The enrollment proceeds if the action is not cancelled after the timeout. Additionally, if the secure-boot-enroll option is set to 'force' then the keys located in the directory named 'auto' are going to be enrolled automatically. The user is still going to be shown a screen allowing them to cancel the action if they want to, however the enrollment will proceed automatically after a timeout without user cancellation. After keys are enrolled, the system reboots with secure boot enabled therefore, it is ***critical*** to ensure that everything needed for the system to boot is signed properly (sd-boot itself, kernel, initramfs, PCI option ROMs). This feature currently only allows loading the most simple set of variables: PK, KEK and db. The files need to be prepared with cert-to-efi-sig-list and then signed with sign-efi-sig-list. Here is a short example to generate your own keys and the right files for auto-enrollement. ` keys="PK KEK DB" uuid="{$(systemd-id128 new -u)}" for key in ${keys}; do openssl req -new -x509 -subj "/CN=${key}/ -keyout "${key}.key" -out "${key}.crt" openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer" cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl.nosign" done sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl.nosign PK.esl sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl.nosign KEK.esl sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl.nosign db.esl ` Once these keys are enrolled, all the files needed for boot ***NEED*** to be signed in order to run. You can sign the binaries with the sbsign tool, for example: ` sbsign --key db.key --cert db.crt bzImage --output $ESP/bzImage ` Example: Assuming the system has been put in Setup Mode: ` $ESP/loader/keys/auto/db.esl $ESP/loader/keys/auto/KEK.esl $ESP/loader/keys/auto/PK.esl $ESP/loader/keys/Linux Only/db.esl $ESP/loader/keys/Linux Only/KEK.esl $ESP/loader/keys/Linux Only/PK.esl $ESP/loader/keys/Linux and Windows/db.esl $ESP/loader/keys/Linux and Windows/KEK.esl $ESP/loader/keys/Linux and Windows/PK.esl ` If auto-enroll is set, then the db, KEK and then PK are enrolled from the 'auto' directory. If not, three new boot entries are available to the user in order to enroll either the 'Linux Only', 'Linux And Windows' or 'auto' set of keys.
Diffstat (limited to 'man/loader.conf.xml')
-rw-r--r--man/loader.conf.xml45
1 files changed, 45 insertions, 0 deletions
diff --git a/man/loader.conf.xml b/man/loader.conf.xml
index 3606de5704..acddb193d1 100644
--- a/man/loader.conf.xml
+++ b/man/loader.conf.xml
@@ -223,6 +223,51 @@
</varlistentry>
<varlistentry>
+ <term>secure-boot-enroll</term>
+
+ <listitem><para>Danger: this feature might soft-brick your device if used improperly.</para>
+
+ <para>Takes one of <literal>off</literal>, <literal>manual</literal> or <literal>force</literal>.
+ Controls the enrollment of secure boot keys. If set to <literal>off</literal>, no action whatsoever
+ is taken. If set to <literal>manual</literal> (the default) and the UEFI firmware is in setup-mode
+ then entries to manually enroll Secure Boot variables are created in the boot menu. If set to
+ <literal>force</literal>, in addition, if a directory named <filename>/loader/keys/auto/</filename>
+ exists on the ESP then the keys in that directory are enrolled automatically.</para>
+
+ <para>The different sets of variables can be set up under <filename>/loader/keys/<replaceable>NAME</replaceable></filename>
+ where <replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry.
+ This allows to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.</para>
+
+ <para>Supported secure boot variables are one database for authorized images, one key exchange key (KEK)
+ and one platform key (PK). For more information, refer to the <ulink url="https://uefi.org/specifications">UEFI specification</ulink>,
+ under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the
+ <ulink url="https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot">
+ EDK2 documentation</ulink>.</para>
+
+ <para>A complete set of UEFI variable includes <filename>db.esl</filename>, <filename>KEK.esl</filename>
+ and <filename>PK.esl</filename>. Note that these files need to be authenticated UEFI variables. See
+ below for an example of how to generate them from regular X.509 keys.</para>
+
+ <programlisting>uuid=$(systemd-id128 new --)
+for key in PK KEK db; do
+ openssl req -new -x509 -subj "/CN=${key}/ -keyout "${key}.key" -out "${key}.crt"
+ openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"
+ cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.tmp"
+done
+
+sign-efi-sig-list -c PK.crt -k PK.key PK PK.tmp PK.esl
+sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.tmp KEK.esl
+sign-efi-sig-list -c KEK.crt -k KEK.key db db.tmp db.esl
+ </programlisting>
+
+ <para>This feature is considered dangerous because even if all the required files are signed with the
+ keys being loaded, some files necessary for the system to function properly still won't be. This
+ is especially the case with Option ROMs (e.g. for storage controllers or graphics cards). See
+ <ulink url="https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom">Secure Boot and Option ROMs</ulink>
+ for more details.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>reboot-for-bitlocker</term>
<listitem><para>Caveat: This feature is experimental, and is likely to be changed (or removed in its