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.
The macro is ugly and annoying to use and provides no real benefit. The
only reason to use it would be to allow warnings to go through. But any
EFI APIs we call do not return warning status codes or we do not check
the return value anyway. The only other case would be BS->StartImage,
where we already treat anything other than EFI_SUCCESS as an error
anyway.
This also helps the compiler and code analyzers to better reason about
the code. In particular, this can help reduce use of uninitialized
variable warnings.
Currently, -Wall and -Wextra override previously passed flags like
-Wno-unused-parameter. This reorders them to be passed before any
optional flags. -Wsign-compare is part of -Wextra and therefore dropped.
-nostdlib is a link-stage flag and dropped as it is already part of
efi_ldflags.
Lennart Poettering
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Michael Biebl
Jan Janssen
Luca Boccassi
nl6720
Yu Watanabe
David Tardon
Shreenidhi Shedi