The verb s not really specific to credential management, it was always a
bit misplaced. Hence move it to systemd-analyze, where we already have
some general TPM related verbs such as "srk" and "pcrs"
This is a rework of e7a93e7521: instead of
handling components with n_variants being zero at every step of the way, we instead
remove it from our list after loading all components, given that such a
component simply makes not sense for the rest of our logic.
If we operate in "offline" mode, i.e. know the device key, then we will
not have a TPM2 connection, hence don't try to read the PCR bank to use form
it.
We don't need it anyway because we are not going to test unseal things.
Fixes: #33855
Such a policy won't provide any protection, but it's still entirely fine
to have it like this in various contexts, for example at OS install
time, to allocate the nvindex and reference it in enrollments. However,
it does deserve mention, hence log about it at LOG_NOTICE level.
This is based on a similar patch by Arnaud Patard
<arnaud.patard@collabora.com> proposed at #33663.
These variables closely mirror the existing
LoaderDevicePartUUID/LoaderImageIdentifier variables. But the Stub…
variables indicate the location of the stub/UKI (i.e. of systemd-stub),
while the Loader… variables indicate the location of the boot loader
(i.e. of systemd-boot). (Except of course, there is no boot loader used,
in which case both sets point to the stub/UKI, as a special case).
This actually matters, as we support that sd-boot runs off the ESP,
while a UKI then runs off XBOOTLDR, i.e. two distinct partitions.
Let's always check if we have data to set *first*, and only then check
if an EFI var is already set.
Checking for the EFI var is more expensive after all.
If this is not done, and there are two images, image_1.raw and image_2.raw under
an image.raw.v folder, then the log will say "Using extensions image" instead of
using "Using extensions image_2.raw" which is the desired behavior for v-picked extensions.
Now that we have multi-profile UKIs people likely want to stick more PE
sections into them than before. Hence, bump the number of available PE
section slots to 30 (up from 15). Also, make this configurable at build
time since some folks probably want even more, and others don't want
this at all.
(pre-allocating too many shouldn't matter too much btw, I'd advise
everyone to overshoot, except maybe on the tiniest of embedded boards)
Let's make use of libcryptsetup's new crypt_token_set_external_path()
API in place of the interposition stuff we have been doing before. Let's
kill it entirely, given that this was a developer feature only anyway
(and guarded by an appropriate ifdef).
Fixes: #30098
Login shells are supposed to marked via a dash as first char. We follow
that logic, but right now we simply overwrite the first char of the
shell. That might not be the right choice, given that this turns
"zsh" into "-sh", which suggests some bourne shell process.
Hence, let's correct things, and instead prefix a dash, which should be
safer.
Inspired by findings on https://github.com/systemd/systemd/issues/34153#issuecomment-2338104907
