This adds support for the EFI stub to look for credential files and
sysext files next to the EFI kernel image being loaded, and pack them up
in an initrd cpio image, and pass them to the kernel.
Specifically, for a kernel image foo.efi it looks for
foo.efi.extra.d/*.cred and packs these files up in an initrd, placing it
inside a directory /.extra/credentials/. It then looks for
foo.efi.extra.d/*.raw and pack these files up in an initrd, placing them
inside a directory /.extra/sysexts/. It then concatenates any other
initrd with these two initrds, so they are combined.
Or in other words auxiliary files placed next to the kernel image are
picked up automatically by the EFI stub and be made available in the
initrd in the /.extra/ directory.
What's the usecase for this? This is supposed to be useful in context of
implementing fully trusted initrds, i.e. initrds that are not built
locally on the system and unsigned/unmeasured – as we do things
currently —, but instead are built by the vendor, and measured to TPM.
The idea is that a basic initrd is always linked into the kernel EFI
image anyway. This will already be sufficient for many cases. However,
in some cases it is necessary to parameterize initrds, or to extend the
basic initrds with additional subsystems (e.g. think complex storage, or
passing server info/certificates/… to initrds). The idea is that the
parameterization is done using the "credentials" logic we already have
in systemd, with these credential files (which can optionally be
encrypted+authenticated by TPM2) being placed in the ESP next to the
kernel image. And the initrd extension via the "sysext" logic we already
have in systemd too.
Note that the files read by this code are not verified immediately, they
are copied *as-is* and placed into /.extra/ in the initrd. In a trusted
environment they need to be validated later, but before first use. For
the credentials logic this should be done via the TPM2
encryption/authentication logic. For the sysext stuff the idea is that
this is done via signed images, as implemented by #20691.
"bootctl update" tries to add sd-boot to the EFI boot loader list if it
is not already there. To do so, it uses find_slot() which finds the
proper BootXXXX slot ID to use and also returns 1 if an existing sd-boot
entry was found at this ID or 0 if it is a new unused ID. In "update"
case install_variables() only writes the entry in case 0 (no existing
entry).
However, find_slot() erroneously returns 1 if it finds a gap in the Boot
IDs (i.e. when not resorting to max(ids) + 1). This causes
"bootctl update" to not add a missing systemd-boot boot entry if the
existing BootXXXX entry IDs are not consecutive.
Fix that by returning 0 in find_slot() when an empty gap ID is selected
to make it match the behavior when selecting an empty non-gap ID.
In a follow-up patch we are going to modify the initrd, hence prepare
the pointers/"physical addresses" to it, first, so that we can do so
easily.
Also, do some other tweaks and cleanups to physical address/pointer
conversion.
The Bootloader Specification says "devicetree refers to the binary
device tree to use when executing the kernel..", but systemd-boot
didn't actually do anything when encountering this stanza until now.
Add support for loading, applying fixups if relevant, and installing the
new device tree before executing the kernel.
When pulling in the SHA256 implementation from glibc, only some of the
coding style was adjusted to ours, other was not. Let's make things a
bit more consistent.
The GUIDs we usually deal with should be considered constant. Hence make
them so. Unfortunately the prototypes for various functions doesn't mark
them as const (but still decorates them with "IN", clarifying they are
input-only), hence we need to cast things at various places. We already
cast in similar fashion in many other cases, hence unify things here in
one style.
Making the EFI_GUID constant (and in particular so when specified in C99
compound literal style) allows compilers to merge multiple instances of
them.
Callers to linux_exec() are actually passing an EFI_HANDLE, not a pointer to
it. linux_efi_handover(), which is called by linux_exec(), also expects an
EFI_HANDLE.
Firmware likes to draw the EFI provided cursor in a weird way that
makes it invisible sometimes. This is even more likely to happen
if unusual colors are picked. It also fails to draw attention to the
user by being very small and not blinking.
Additionally, to make it more clear that we are in edit mode, we
now default to inverting the general default color and use that for
our line edit.
Fixes: #19301
Making keys case insensitive should help if caps lock is on.
We are not advertising them at runtime or in the manual to
reduce the noise.
This also hides the quit and version commands from the help
string. They are mostly for devs and otherwise have little
to no use to normal users. The latter overlaps with print
status which is still advertised.
We only need the PE header offset from the DOS header, not
its size. Previously, the section table could be cut off in the middle.
While we are at it, also modernize the remaining code.
There is a ASSERT() macro from gnu-efi, but that does not show any
output to ConOut. Having to do some additional setup just to get
some debug output is tedious and outright difficult on real hardware.
log_error_stall() and log_error_status_stall() will ensure the user has
a chance to catch an error message by stalling and also forcing a
lightred/black color on it. Also, convert several Print() calls to it
since they are actually error messages.
Let's be paranoid and do something useful if we operate with empty
haystack/needle. This doesn't actually fix anything, as the places as
far as I can see check for non-emptyness already beforehand, but I will
sleep safer at night, if we don't even allow the trap to be fallen in,
ever, even if the code is changed sooner or later.
This is like memmem_safe() but returns a pointer after the needle,
instead to the beginning of the needle.
This is then used at one place. Not much, but it makes me sleep safer at
night, as it avoids the manual counting done so far.
When boot ArchLinux from Ventoy, it always print `Failed to open random seed file: write protected.`
As Ventoy emulate the ISO file as a read-only CDROM, I didn't test with a real physical CDROM drive, but maybe it also has such problem.
As we use `EFI_FILE_MODE_WRITE` to open the `loader\random-seed` file, so I think it's better to check the result with both `EFI_WRITE_PROTECTED` and `EFI_NOT_FOUND`.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
Previously, the "bootctl update" logic would refrain from downrgading a
boot loader, but if the boot loader that is installed already matched
the version we could install we'd install it anyway, under the
assumption this was effectively without effect. This behaviour was handy
while developing boot loaders, since installing a modified boot loader
didn't require a version bump.
However, outside of the systems of boot loader developers I don't think
this behaviour makes much sense: we should always emphasize doing
minimal changes to the ESP, hence when an update is supposedly not
necessary, then don't do it. Only update if it really makes sense, to
minimize writes to the ESP. Updating the boot loader is a good thing
after all, but doing so redundantly is not.
Also, downgrade the message about this to LOG_NOTICE, given this
shouldn't be a reason to log.
Finally, exit cleanly in this cases (or if another boot loader is
detected)