In confidential computing, a virtual firmware may support measurement and
event log based upon the hardware Trusted Execution Environment (TEE)
capability.
The UEFI specification defines an interface between the virtual guest OS
and virtual firmware as EFI_CC_MEASUREMENT_PROTOCOL. The (vendor specific)
measurements are captured in the CC eventlog that follows the TCG2 format.
OVMF virtual firmware has the EFI_CC_MEASUREMENT_PROTOCOL support for
Intel Trust Domain Extensions (TDX). Intel TDX has 4 runtime measurement
registers (RTMR) defined as:
RTMR[0] for TDVF configuration
RTMR[1] for the TD OS loader and kernel
RTMR[2] for the OS application
RTMR[3] reserved for special usage only
The RTMR to PCR mappings are defined in the UEFI Spec 2.10 Section 38.4.1
as follows:
TPM PCR Index | CC Measurement Register Index | TDX-measurement register
------------------------------------------------------------------------
0 | 0 | MRTD
1, 7 | 1 | RTMR[0]
2-6 | 2 | RTMR[1]
8-15 | 3 | RTMR[2]
The CC measurement eventlog is currently exposed as a raw CCEL ACPI table
by the guest OS and the events can be replayed to check log matches with
the RTMR values.
Add EFI CC measurement protocol to stub to get the UKI components measured
and included in the remote attestation reports when vTPMs are not available.
This isn't a failure we care about, and it's somewhat alarming to see a
red error message flash up on the display when booting, so this just
simply returns EFI_SUCCESS and skips printing the "error" altogether.
This does what we do for system extension also for configuration
extension.
This is complicated by the fact that we previously looked for
<uki-binary>.d/*.raw for system extensions. We want to measure sysexts
and confexts to different PCRs (13 vs. 12) hence we must distinguish
them, but *.raw would match both kinds.
This commit solves this via the following mechanism: we'll load confexts
from *.confext.raw and sysexts from *.raw but will then enclude
*.confext.raw from the latter. This preserves compatibility but allows
us to somewhat reasonable distinguish both types of images.
The documentation is updated not going into this detail though, and
instead now claims that sysexts shall be *.sysext.raw and confexts
*.confext.raw even though we actually are more lenient than this. This
is simply to push people towards using the longer, more descriptive
suffixes.
I added an XML comment (<!-- … -->) about this to the docs, so that
whenever somebody notices the difference between code and docs
understands why and leaves it that way.
systemd-boot might be installed in /EFI/BOOT under more names than
just /EFI/BOOT/BOOTX64.efi. The prime example is shim which loads
its second stage binary from /EFI/BOOT/grubx64.efi. To accomodate
use cases where systemd-boot is installed as /EFI/BOOT/grubx64.efi,
let's always check the entire /EFI/BOOT directory for binaries that
identify as systemd-boot and list/update/remove those as well.
Let's keep this somewhat generic though and not install ourselves as
grubx64.efi since that would mean having to check for shim which is
a can of worms we probably don't want to open.
Output is otherwise so weird, since this is the last log line seen for a
while typically, and if it doesn#t put the cursor back in the first
column it looks like something is incomplete and hanging. Hence do what
we always do: finish log messages with a newline.
Firmware may not have loaded a devicetree, for example if the device
shipped with windows and exclusively supports ACPI.
We should always load the specified devicetree regardless of firmware
state to enable booting on platforms where Linux only supports DT.
Note: in _cleanup, the orig. config is NULL in this case, and passing
NULL to InstallConfigurationTable is permitted by the EFI spec.
See: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.htmlFixes#24059
Co-authored-by: Daniel Thompson <daniel.thompson@linaro.org>
When testing the secureboot enroll feature, it can be hard to distinguish without
using the QMP API of QEMU whether we are in a hang situation of the UEFI firmware.
Making it clear that we reached the `ResetSystem` can be helpful towards that need.
Same idea as with bootctl, we might be doing image builds from a
system that doesn't boot with UEFI but we still might want to measure
stuff for the image we're building so let's not gate this behind
ENABLE_BOOTLOADER.
bootctl is rather useful to have, even if on a system without UEFI,
as it has a number of verbs that are unrelated to UEFI (e.g kernel-identify),
and more importantly, it supports --root to operate on directory trees
(which could be intended to be deployed on UEFI) so let's make sure we
always build it.
If `foo+3-0.efi` is booted when there are some files in `foo.efi.extra.d`,
those files are ignored. But after the boot is blessed and the system rebooted,
those file are taken into account, and the boot is different from first
boot. This behavior is a bit puzzling.
Instead we now ignore the counter and always look for the extra files in
`foo.efi.extra.d` and always boot the same way.
Ultimately we want to be able to recognize these in userspace, hence
make them available in both UEFI mode and userspace.
While we are at it, let's rename the fields a bit, reflecting more what
they measure, not what the metadata is that we store about them.
We usually check return value of syscalls or glibc functions by it is
negative or not, something like that `if (stat(path, &st) < 0)`.
Let's also use the same style for lseek() and friends even the type of
their return value is off_t.
Note, fseeko() returns int, instead of off_t.
Currently we have a 100ms delay which allows for people to enter/show
the boot menu even when timeout is set to zero.
In a handful of cases, that may not be needed - both in terms of access
policy, as well as latency.
For example: the option to provide the boot menu may be hidden behind an
"expert only" UX in the OS, to avoid end users from accidentally
entering it.
In addition, the current 100ms input polling may cause unexpected
additional delays in the boot. Some example numbers from my SteamDeck:
- boot counting/rename/flush doubles 300us -> 600us
- seed/hash setup doubles 900us -> 1800us
- kernel/image load gets ~40% slower 107ms -> 167ms
It's not entirely clear why the UEFI calls gets slower, nevertheless the
information in itself proves useful.
This commit introduces a new option "menu-disabled", which omits the
100ms delay. The option is documented throughout the manual pages as
well as the Boot Loader Specification.
v2:
- use STR_IN_SET
v3:
- drop erroneous whitespace
v4:
- add a new LoaderFeature bit,
- don't change ABI keep TIMEOUT_* tokens the same
- move new token in the 64bit range, update API and storage for it
- change inc/dec behaviour to TIMEOUT_MIN : TIMEOUT_MENU_FORCE
- user cannot opt-in from sd-boot itself, add assert_not_reached()
v5:
- s/Menu disablement control/Menu can be disabled/
- rewrap comments to 109
- use SYNTHETIC_ERRNO(EOPNOTSUPP)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
UKIs may be loaded in a way, that there can not be a device handle to
the filesystem, that contains the image, for example when using a
bootloader to load the image from a partition with a file system that is
not supported by the firmware.
With the current systemd stub, this causes a failed assertion, because
stub gets passed a NULL DeviceHandle and FilePath. Inserting two
explicit checks enables proper boot even in this case.
Fixes: #29331
Some of the entries are really configured, but we also have a bunch
of automatic entries. Calling them "config entries" is misleading, let's
use the more natural "boot entry".
While at it, rename:
config_load_entries() → config_load_type1_entries()
config_entry_add_unified() → config_load_type2_entries()
config_title_generate() → generate_boot_entry_titles()
config_entry_add_<type>() → config_add_entry_<type>()
No functional change.
When the user pressed + or -, we would set the efivar override, starting
from the default of 0. Instead, set an override that starts at the current
value. This means that when user has e.g. a configured override of 5 s, and
they press +, they get an override of 6 s. I think this is leads to a much
smoother experience for a user, who does not necessarilly need to know that
we have three levels of overrides, they just want to easily configure the
timeout with keys. If they press +, the timeout should increase, and not
jump to some low value.
Also, once an override has been set via the boot menu, i.e. the efivar is set,
do not allow unsetting the efivar from the boot menu. This way we also avoid
an unexpected "jump" to whatever the other sources of configuration specify.
The user can configure any value with the keys that they want, so we don't
need to allow unsetting.
The menu_run() function allows the user to set/unset default entry, or to
increase/decrease menu timeout. After a keypress, status like
"Menu timeout set to 5 s"
is printed, but there actually isn't any immediate effect. The value is only
written right right before booting a menu entry to avoid unnecessary wear&tear
on the nvram storage. This delayed write is supposed to be invisible to the
user.
Nevertheless, operations like reboot into firmware, reboot, or shutdown were
done immediately. We need to exit the loop first, save the state, and only do
the op afterwards.
Fixup for f6531b11d2 and
e6cab77eca.
Also reverts 498d0cc426.
Mikko Ylinen
Antonio Alvarez Feijoo
Clayton Craft
Lennart Poettering
Frantisek Sumsal
Daan De Meyer
Rose
Mike Yuan
Yu Watanabe
Raito Bezarius
Luca Boccassi
Valentin David
Zbigniew Jędrzejewski-Szmek
Emil Velikov
Lukas
Jan Janssen