$ journalctl -u systemd-bless-boot.service
systemd[1]: Starting Mark the Current Boot Loader Entry as Good...
systemd-bless-boot[536]: Marked boot as 'good'. (Boot attempt counter is at 2.)
systemd-bless-boot[536]: Can't find boot counter source file for '/loader/entries/arch.conf': Device or resource busy
systemd[1]: Finished Mark the Current Boot Loader Entry as Good.
The stub image may not have enough sections to cause enough PE header
space to be free for later expansion. Given that the stub is guaranteed
to be expanded we should always reserve enough sections for it.
This also bumps the reservation to 15. It doesn't add more space
compared to current builds but it more closely reflects the amount of
sections that a UKI could have in total if all optional sections are
used.
Fixes: #28593
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
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.
Jan Janssen
Yu Watanabe
Luca Boccassi
Daan De Meyer
Dmitry V. Levin
Zbigniew Jędrzejewski-Szmek
Daniel P. Berrangé
Lennart Poettering
Mike Yuan
Dan Streetman
Arian van Putten