Adding Microsoft keys by default is recommended because firmware drivers
might be signed by it.
This also changes the file ending from .esl to .auth as that is used by
sign-efi-sig-list manpage and other sources.
***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.
For now, this simply outputs the PCR hash values expected for a kernel
image, if it's measured like sd-stub would do it.
(Later on, we can extend the tool, to optionally sign these
pre-calculated measurements, in order to implement signed PCR policies
for disk encryption.)
Previously, the tree output of discovered boot laoders in the ESP would
look like this:
Available Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/0c6f41ed-2573-4723-8c84-23681f9d1c28)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot v250.7-1.fc36)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot v250.7-1.fc36)
With this change the tree branches are corrected to look like this:
Available Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/0c6f41ed-2573-4723-8c84-23681f9d1c28)
File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot v250.7-1.fc36)
└─/EFI/BOOT/BOOTX64.EFI (systemd-boot v250.7-1.fc36)
Ahhh! So much nicer. This incorrect tree drawing has been bugging me for
so long. Finally I can sleep at night again!
This is not actually used (or even supposed to be used) in clean
codepaths, but is tremendously useful when verifying things work
correctly, as a debugging tool.
Report whether the devicetree + sort-key boot loader spec type #1
fields are supported, and whether the "@saved" pseudo-entry is
supported.
Strictly speaking, thes features have been added in versions that are
already released (250+), so by adding this those version even though
they support the features will be considered not supporting them, but
that should be OK (the opposite would be a problem though, i.e. if we'd
assume a boot loader had a feature it actually does not).
These three features are features relevant to userspace, as it allows
userspace to tweak/genereate BLS entries or set EFI vars correctly.
Other features (i.e. that have no impliciations to userspace) are not
reported.
Let's be a bit more careful when converting the UTF-16 cmdline to ASCII.
Let's convert all characters out of the printable ASCII range to spaces,
instead of blindly relying on C's downcasting behaviour.
systemd-boot reports its features via the LoaderFeatures EFI variable.
Let's add something similar for stub features, given they have been
growing.
For starters only define four feature flags. One is a baseline feature
we pretty much always supported (see comment in code), two are features
added in one of the most recently released systemd version, and the
final one, is a feature we added a few commits ago.
This is useful for userspace to figure out what is supported and what
not.
Let's grab another so far unused PCR, and measure all sysext images into
it that we load from the ESP. Note that this is possibly partly redundant,
since sysext images should have dm-verity enabled, and that is hooked up
to IMA. However, measuring this explicitly has the benefit that we can
measure filenames too, easily, and that all without need for IMA or
anything like that.
This means: when booting a unified sd-stub kernel through sd-boot we'll
now have:
1. PCR 11: unified kernel image payload (i.e. kernel, initrd, boot
splash, dtb, osrelease)
2. PCR 12: kernel command line (i.e. the one embedded in the image, plus
optionally an overriden one) + any credential files picked up by
sd-stub
3. PCR 13: sysext images picked up by sd-stub
And each of these three PCRs should carry just the above, and start from
zero, thus be pre-calculatable.
Thus, all components and parameters of the OS boot process (i.e.
everything after the boot loader) is now nicely pre-calculable.
NOTE: this actually replaces previous measuring of the syext images into
PCR 4. I added this back in 845707aae2,
following the train of thought, that sysext images for the initrd should
be measured like the initrd itself they are for, and according to my
thinking that would be a unified kernel which is measured by firmware
into PCR 4 like any other UEFI executables.
However, I think we should depart from that idea. First and foremost
that makes it harder to pre-calculate PCR 4 (since we actually measured
quite incompatible records to the TPM event log), but also I think
there's great value in being able to write policies that bind to the
used sysexts independently of the earlier boot chain (i.e. shim, boot
loader, unified kernel), hence a separate PCR makes more sense.
Strictly speaking, this is a compatibility break, but I think one we can
get away with, simply because the initrd sysext images are currently not
picked up by systemd-sysext yet in the initrd, and because of that we
can be reasonably sure noone uses this yet, and hence relies on the PCR
register used. Hence, let's clean this up before people actually do
start relying on this.
Here we grab a new – on Linux so far unused (by my Googling skills, that
is) – and measure all static components of the PE kernel image into.
This is useful since for the first time we'll have a PCR that contains
only a PCR of the booted kernel, nothing else. That allows putting
together TPM policies that bind to a specific kernel (+ builtin initrd),
without having to have booted that kernel first. PCRs can be
pre-calculated. Yay!
You might wonder, why we measure just the discovered PE sections we are
about to use, instead of the whole PE image. That's because of the next
step I have in mind: PE images should also be able to carry an
additional section that contains a signature for its own expected,
pre-calculated PCR values. This signature data should then be passed
into the booted kernel and can be used there in TPM policies. Benefit:
TPM policies can now be bound to *signatures* of PCRs, instead of the
raw hash values themselves. This makes update management a *lot* easier,
as policies don't need to be updated whenever a kernel is updated, as
long as the signature is available. Now, if the PCR signature is
embedded in the kernel PE image it cannot be of a PCR hash of the kernel
PE image itself, because that would be a chicken-and-egg problem. Hence,
by only measuring the relavent payload sections (and that means
excluding the future section that will contain the PCR hash signature)
we avoid this problem, naturally.
the measurement calls can succeed either when they actually measured
something, or when they skipped measurement because the local system
didn't support TPMs.
Let's optionally return a boolean saying which case it is. This is later
useful to tell userspace how and if we measured something.
The other variables are owned by the boot menu (i.e. sd-boot), we only
fill those in if it didn't do so for us (to support cases where our stub
kernel is directly invoked by UEFI). But StubInfo is genuinely about the
stub, hence let's simplify things and unconditionally set it from the
stub.
THis will be useful in a later commit, when we add more stuff to the
common exit path. But even without that, it's a nice simplification,
removing redundant lines.
We allow ESP autodetection to fail, e.g. if it is not mounted, but then we'd
say that the detected one is different than the one reported by the bootloader,
which is rather confusing.
While at it, if we actually detect a mismatch, print the two uuids.
Newer binutils versions currently trigger the following warnings due to
a bug in gnu-efi
on arm64:
/usr/bin/ld.bfd: warning: src/boot/efi/systemd-bootaa64.elf has a LOAD segment with RWX permissions
on amd64:
/usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
This results in a build failure due to --fatal-warnings.
Work around this issue by suppressing those warnings until gnu-efi has
been fixed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013341
When using --root=/--image= the binaries to install/update will be
picked from the directory/image. Add an option to let the caller
choose.
By default (auto) the image is tried first, and if nothing is found
then the host. The other options allow to strictly try the image
or host and ignore the other.
These are somewhat pointless gnu-efi typedefs. Using the names from the
UEFI spec makes things clearer.
The one exception left is EFI_FILE as we use it a lot and
EFI_FILE_PROTOCOL is quite a handful.
The way the UEFI spec defines BOOLEAN is fully compatible to stdbool, so
it is perfectly safe to switch to it. Although any other values than 0/1
are undefined by the spec, we could theoretically have cases where a
sloppy firmware hands us a bad BOOLEAN (since gnu-efi/edk2 declare it
as uint8_t). So any uses where we pass a pointer to BOOLEAN are left
untouched.
Frantisek Sumsal
Yu Watanabe
Jan Janssen
Vincent Dagonneau
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Michael Biebl
Luca Boccassi
nl6720
David Tardon