As mentioned in the NEWS entry, it seems to see very little use, but adds
complexity in our code. It was added mainly with the goal of making it easier
for people using grub2 to modify their boot configuration, but grub2 is gaining
support for BLS snippets. On the systemd side, we now have credentials. So
let's deprecate this, and if there's no outcry, remove it in a few releases.
This helper is a simplified version of detect_confidential_virtualization()
that merely returns a boolean status flag reflecting whether we are believed
to be running inside a confidential VM.
This flag can be used for turning off features that are inappropriate to
use from a CVM, but must not be used for releasing sensitive data. The
latter must only be done in response to an attestation for the environment.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When building on a x32 system we need to explicitly pass `-m64` to get
the right ABI as the kernel and EFI are still 64bit. For this to
actually work, a suitable multilib compiler, 32bit libc headers and
libgcc need to be installed (similar to ia32 builds on x86_64).
While we don't strictly follow the rule, most of our userspace names
these fields that count entries in some array n_xyz, hence let's do so
in the EFI boot code too, to make things less special.
We gained a bunch of new features that deserve reporting to userspace,
hence add matching flags for each.
This allows userspace to determine if installing addons in the ESP even
makes sense.
This is inspired by a similar changes in #28057
The UEFI spec has a generic `Path` node representation that can be used
for device path nodes that are unknown. So we can use that instead of
giving up when we see a node other than FilePath.
This also simplifies the FilePath case by just using xasprintf(). The
code is really just a fallback for silly firmware that does not
implement EFI_DEVICE_PATH_TO_TEXT_PROTOCOL (looking at you, Apple).
The correctness of this was tested by round-tripping it through
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL, which yielded an identical device
compared to our input path.
This takes heavy inspiration from @zx2c4 (Jason A. Donenfeld)'s
PR #25531 but changes it considerably, but always going by fd instead of
paths, and only warning about the side file itself and the ESP mount
point, nothing else. This shuld be more than enough and should not be
brittle against concurrent path modifications.
Replaces: #25531
This changes a boolean param into a proper bitflag field.
Given this only defines a single flag for now this doesn't look like
much of an improvement. But we'll add another flag shortly, where it
starts to make more sense.
We are using HandleProtocol everywhere except in these few cases. This
unifies on HandleProtocol as it is simpler to use and equivalent to
OpenProtocol.
The only difference between the two is that OpenProtocol attributes the
opened protocol to a firmware-owned handle instead of our image handle.
This has no real use for regular UEFI applications as any protocols
opened via BY_HANDLE or GET_PROTOCOL is not required to be closed. In
fact, when a protocol is uninstalled it will do nothing more than reduce
the open count for these.
Remove _cleanup_tpm2_context_ and _cleanup_tpm2_handle_ macros, replacing their
use with _cleanup_(tpm2_context_unrefp) and _cleanup_(tpm2_handle_freep),
respectively.
Without this, the tests would generally be skipped, since we haven't made a
release with the addon stub yet. But even if the file is there, we always want
to test the freshly-built item.
Previously, unprivileged mode for find_esp_and_warn() and
find_xbootldr_and_warn() could be enabled or disabled. With this change
it can also be set to negative in which case the functions will enable
it automatically if found to be executing without privileges.
This just moves te geteuid() check we often do for the param inside of
the functions.
At the same time internally in the functions we also pass around the
VerifyESPFlags field across the various functions instead of booleans.
Both changes are just refactoring. No changes in behaviour.
In 9b9f6aa412 (#27069)
we changed get_file_version to return 0 instead of 1 on success.
However we did not update the printing of the version number to
handle this change so we would never print the version number.
Files placed in /EFI/Linux/UKI.efi.extra.d/ and /loader/addons/ are
opened and verified using the LoadImage protocol, and will thus get
verified via shim/firmware.
If they are valid signed PE files, the .cmdline section will be
extracted and appended. If there are multiple addons in each directory,
they will be parsed in alphanumerical order.
Optionally the .uname sections are also matched if present, so
that they can be used to filter out addons as well if needed, and only
addons that correspond exactly to the UKI being loaded are used.
It is recommended to also always add a .sbat section to addons, so
that they can be mass-revoked with just a policy update.
The files must have a .addon.efi suffix.
Files in the per-UKI directory are parsed, sorted, measured and
appended first. Then, files in the generic directory are processed.
We'll use it from the stub to validate files. Requires Shim 5.18.
By default, Shim uninstalls its protocol when calling StartImage(),
so when loading systemd-boot via shim and then loading an UKI, the
UKI's sd-stub will no longer be able to use the shim verification
protocol by default.
Daan De Meyer
Luca Boccassi
Jan Janssen
Zbigniew Jędrzejewski-Szmek
Daniel P. Berrangé
Lennart Poettering
Mike Yuan
Dan Streetman
Yu Watanabe
Arian van Putten
Frantisek Sumsal