This is supposed to be useful when generating credentials for immutable
initrd environments, where it is is relevant to support credentials even
on systems lacking a TPM2 chip.
With this, if `systemd-creds encrypt --with-key=auto-initrd` is used a
credential will be encrypted/signed with the TPM2 if it is available and
recognized by the firmware. Otherwise it will be encrypted/signed with
the fixed empty key, thus providing no confidentiality or authenticity.
The idea is that distributions use this mode to generically create
credentials that are as locked down as possible on the specific
platform.
Previously, when encrypting creds you could pick which key to use for
this via a 128bit ID identifying the key type, and use an all zero ID
for rquesting automatic mode.
Let's change this to use an explicitly picked 128bit ID for automatic
mode, i.e. something other than all zeros. This is in preparation for
adding one further automatic mode with slightly different semantics.
no change in behaviour.
Note that the new 128bit id is never written to disk but only used
internally to indicate a specific case.
Sometimes it's useful from shell scripts to check if we have a working
TPM2 chip around. For example, when putting together encrypted
credentials for the initrd (after all: it might be wise to place the
root pw in a credential for the initrd to consume, but do so only if we
can lock it to the TPM2, and not otherwise, so that we risk nothing).
Hence, let's add a new "systemd-creds has-tpm2" verb: it returns zero if we
have a working TPM2 (which means: supported by kernel + firmware + us),
or non-zero otherwise. Also show which parts are available.
Use-case: in future the 'kernel-install' script should use this when
deciding whether to augment kernels with security sensitive credentials.
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.
Lennart Poettering
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Frantisek Sumsal