Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
I think the current behaviour of not doing EFI variables when we are run
in a container makes a ton of sense, but in some cases it's useful to
do EFI var setup even when a set of namespaces is set up for us, for
example to recover a hosed installation from a rescue disk.
While we are at it, let's remove some duplicate checks, and
systematically output information why we skip various operations.
Fixes: #36174#35005
The log line looked like this:
bootctl[1457]: ! Mount point '/efi' which backs the random seed file is world accessible, which is a security hole! !
which doesn't look nice.
Also upgrade the message to error. This is something to fix.
Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
... and "Stub/Boot loader set network boot URL information".
This reverts 26bfd97216
('bootctl: also shown whether stub loader partition data was passed'),
and one line from bfcf48b842
('bootctl: show stub partition data too in "status" too'),
and two lines from e15d18b4c6
('sd-stub: if we are http booted, query source URL and write to EFI variable').
As discussed in https://github.com/systemd/systemd/pull/36372, those are not
"features", but optional pieces of information that may or may not be set, also
depending on how the boot loader and stub were loaded. We already prominently
show this information right below: either we print the device path or "n/a" or
skip the output. The user already has all the information, and the status
output should be dense, so it doesn't make sense to repeat this twice.
✓ Boot loader set partition information
Partition: /dev/disk/by-partuuid/3f003ec5-5673-5b4f-b9a4-cbac1ca4461a
OR
- Boot loader set partition information
Partition: n/a
✓ Stub loader set partition information
Partition: /dev/disk/by-partuuid/3f003ec5-5673-5b4f-b9a4-cbac1ca4461a
OR
- Stub loader set partition information
Partition: n/a
Let's not claim the system was not booted with UEFI if we use --image=.
The system wasn't booted at all, after all. Hence supress the whole
section altogether in this case.
Let's make sure we can use the tool on ParticleOS images. They have no
root fs by default (until they are instantiated), but always have /usr/.
Hence add DISSECT_IMAGE_USR_NO_ROOT which has the desired effect.
This has been depracted since v254 (2023). Let's kill it for
good now, it has been long enough with 2y. Noone has shown up who wants
to keep it. And given it doesn't work in SB world anyway, and is not
measured is quite problematic security wise.
This one is between "efi" and "linux": we'll recognize such entries as
linux, but we'll just invoke them as EFI binaries.
This creates a high-level concept for invoking UKIs via indirection of a
bls type #1 entry, for example to permit invocation from a non-standard
path or for giving entries a different name.
Companion BLS spec PR:
https://github.com/uapi-group/specifications/pull/135
(Let's rename LOADER_UNIFIED_LINUX to LOADER_TYPE2_UKI at the same time
to reduce confusion what is what)
Let's move the currently used/default/oneshot entry output after the
basic info about the boot loader itself, since conceptually these are
objects kinda "one level down" from the boot loader perspective. Hence,
let's *first* show all info about the boot loader itself before we
display the objects it manages.
This is just a trivial change in output, just swaps th elines for these
fields with the ones showing where the boot loader is installed.
So far we'd output both the partition and the binary path always, even
if we didn't know either (but in that case show empty information).
Let's address this, and show partition info only if we know it, or if we
know the EFI binary path, but suppress both if we know neither.
Note that we'll show the partition info if we don't know it still if we
know the EFI binary path used for boot, since it is relative to the
partition of course, and hence it's really strange to know one but not
the other, hence it deserves some mentioning in the output.
Let's make the stub and loader output sections more alike, and say in
both cases whether we recieved that data from the boot phase or not the
same way.
This new field allows specification of an fd on which the password
prompt logic will look for POLLHUP events for, and if seen will abort
the query.
The usecase for this is that when we query for a pw on behalf of a
Varlink client we can abort the query automatically if the client dies.
The values that were previously hardcoded in sd-varlink.c are now defined
in new varlink_set_info_systemd() and that function is called everywhere
where we create a server.
The bootspec util-lib's handling of global addons didn't previously
match the behavior of sd-stub, and this commit corrects that.
First, bootspec didn't load global addons from the XBOOTLDR dir, but the
stub does. So, bootspec now enumerates addons in XBOOTLDR, not just ESP
Second, the stub only loads resources (including addons) from the
partition that it was found on. Thus, we must keep track of which
partition the global addons come from, and which partition each boot
entry comes from. In other words: global addons found on the ESP will
NOT apply to UKIs found in XBOOTLDR, and bootspec now reflects that.
systemd-boot uses the existance of loader/keys/auto to determine
whether to auto-enroll secure boot or not so only create the directory
if we're actually going to put auto-enroll signature lists in it.
This allows loading the X.509 certificate from an OpenSSL provider
instead of a file system path. This allows loading certficates directly
from hardware tokens instead of having to export them to a file on
disk first.
