crypt_activate_by_token() fails with ENOANO if the token is protected with a
PIN, in this case we need to call crypt_activate_by_token_pin() with a PIN.
This logic is already implemented in
crypt_activate_by_token_pin_ask_password().
This code path is relevant when using systemd-gpt-auto-generator because there
is no a priory information about the type of the used security device, so
systemd-cryptsetup tries to unlock the volume using the corresponding
cryptsetup plugin.
Use the helper function introduced in the previous commit ("cryptsetup:
implement cryptsetup_token_open_pin for systemd-tpm2 LUKS2 token") for
cryptsetup-token-systemd-tpm2.
This finishes the implementation started in commit
1f895adac2 ("cryptsetup: add libcryptsetup TPM2
PIN support").
Note that the previous implementation took a shortcut by returning EOPNOTSUPP
instead of the correct ENOANO as per the cryptsetup documentation. This meant
that systemd-cryptsetup fell back to the non-plugin implementation in order to
ask for the PIN. Since this does not happen any more when returning ENOANO, we
need to ask for the PIN in attach_luks2_by_tpm2_via_plugin() instead like
attach_luks2_by_fido2_via_plugin() does.
```
...
../src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-fido2.c:33:13: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
int r;
^
1 error generated.
...
../src/cryptsetup/cryptsetup-tokens/cryptsetup-token-systemd-pkcs11.c:34:13: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
int r;
^
1 error generated.
ninja: build stopped: subcommand failed.
+ fatal ''\''meson compile'\'' failed with -Db_ndebug=true'
```
Let's upgrade log levels of some noteworthy messages from LOG_DEBUG to
LOG_NOTICE. These messages contain information that previous log
messages in the error path didn't say, namely that we'll now fall back
to traditional unlocking.
Note that this leaves similar log messages for cases where
TPM2/PKCS#11/FIDO2 support is disabled at build at LOG_DEBUG, since in
that case nothing really failed, we just systematically can't do
TPM2/PKCS#11/FIDO2 and hence it is pointless and not actionable for
users to do anything about it...
The are so many different flavours of functions that attach volumes,
hence say explicitly that these are about libcryptsetup plugins, and
nothing else.
Just some renaming, no code changes beyond that.
Some refactoring: split efi-loader.[ch] in two: isolate the calls that
implement out boot loader interface spec, and those which implement
access to upstream UEFI firmware features.
They are quite different in nature and behaviour, and even semantically
it makes to keep these two separate. At the very least because the
previous name "efi-loader.[ch]" suggests all was about loader-specific
APIs, but much of it is generic uefi stuff...
While we are at it, I renamed a bunch of return parameters to follow our
usual ret_xyz naming. But besides renaming no real code changes.
Handle the case where TPM2 metadata is not available and explicitly
provided in crypttab. This adds a new "tpm2-pin" option to crypttab
options for this purpose.
This is unfinished: we don't have any way to actually query for PINs
interactively this way. It is similar to FIDO2 and PKCS#11 in this
regard.
Nonetheless, this code is capable of validating and dumping tokens, so
it is already useful as-is.
Modify TPM2 authentication policy to optionally include an authValue, i.e.
a password/PIN. We use the "PIN" terminology since it's used by other
systems such as Windows, even though the PIN is not necessarily numeric.
The pin is hashed via SHA256 to allow for arbitrary length PINs.
v2: fix tpm2_seal in sd-repart
v3: applied review feedback
The new helper combines a bunch of steps every invocation of
unsetenv_erase() did so far: getenv() + strdup() + unsetenv_erase().
Let's unify this into one helper that is harder to use incorrectly. It's
in inspired by TAKE_PTR() in a way: get the env var out and invalidate
where it was before.
The way that the cryptsetup plugins were built was unnecessarilly complicated.
We would build three static libraries that would then be linked into dynamic
libraries. No need to do this.
While at it, let's use a convenience library to avoid compiling the shared code
more than once.
We want the output .so files to be located in the main build directory,
like with all consumable build artifacts, so we need to maintain the split
between src/cryptsetup/cryptsetup-token/meson.build and the main meson.build
file.
AFAICT, the build artifacts are the same: exported and undefined symbols are
identical. There is a tiny difference in size, but I think it might be caused
by a different build directory name.
We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.
Let's add configurable timeout how long to wait for FIDO2/PKCS#11
devices to show up. Once the timeout is hit, let's automatically revert
to querying via passphrase.
Fixes: #19739
Before we'd already ask for a PIN just because we know we'll need it
when the token is plugged in. We'd only the try to talk to the device
and notice it actually isn't plugged in. This is quite confusing, as
querying for the PIN suggests we already had a device we are talking to.
Let's hence check if there's actually device before we ask the PIN
question. And if there is none, let's immediately inform the caller, so
that they watch udev and retry once a device has shown up.
The field is not owned by us (even though is in our JSON objects) but by
the LUKS2 spec. Hence let's handle this a bit more gracefully: let's not
get confused by it, just warn and skip over it.
Fixes: #20847
LLVM 13 introduced `-Wunused-but-set-variable` diagnostic flag, which
trips over some intentionally set-but-not-used variables or variables
attached to cleanup handlers with side effects (`_cleanup_umask_`,
`_cleanup_(notify_on_cleanup)`, `_cleanup_(restore_sigsetp)`, etc.):
```
../src/basic/process-util.c:1257:46: error: variable 'saved_ssp' set but not used [-Werror,-Wunused-but-set-variable]
_cleanup_(restore_sigsetp) sigset_t *saved_ssp = NULL;
^
1 error generated.
```
Previously, we hardcoded use of ECC as primary keys, since they are much
faster (i.e. saving multiple seconds) to do TPM2 operations with. Alas,
not all TPM2 chips appear to support ECC. Bummer.
Let's hence add a fallback logic: if we can't create an ECC primary key,
use an RSA key, and store that fact away.
AFIU the security guarantees should be roughly the same, it's just that
RSA primary keys is so much slower to work with than ECC.
The primary key algorithm is used is stored in the JSON header of LUKS
disks, in a new field. If the field is absent we assume to use ECC, to
provide full compatibility with old systemd versions.
The primary key algorithm is stored in a new field in the credentials
file format (in fact, a previously unused zero space is used), too.
Hopefully, this should ensure that TPM2 support will "just work" on more
systems.
Fixes: #20361
cryptsetup_token_dump() gets called when the user calls
"cryptsetup luksDump" for a volume and it prints the token-specific
data.
The tpm2 cryptsetup_token_dump() function misspells tpm2 as tmp2 on two
lines of its output.
Fix that.
Add support for systemd-pkcs11 based LUKS2 device activation
via libcryptsetup plugin. This make the feature (pkcs11 sealed
LUKS2 keyslot passphrase) usable from both systemd utilities
and cryptsetup cli.
The feature is configured via -Dlibcryptsetup-plugins combo
with default value set to 'auto'. It get's enabled automatically
when cryptsetup 2.4.0 or later is installed in build system.
Add support for systemd-fido2 based LUKS2 device activation
via libcryptsetup plugin. This make the feature (fido2 sealed
LUKS2 keyslot passphrase) usable from both systemd utilities
and cryptsetup cli.
The feature is configured via -Dlibcryptsetup-plugins combo
with default value set to 'auto'. It get's enabled automatically
when cryptsetup 2.4.0 or later is installed in build system.
PR #20176 broke building of the cryptsetup token logic. This wasn't
noticed before the PR was merged, because the only CIs new enough to be
able to build the token logic (the Fedora Rawhide ones) didn't actually
run at all on the PR.
Let's add the missing hookup for the TPM2 PCR bank logic also to the
token module, to make the CI pass again.
Previously, we'd encode PCR policies strictly with the SHA256 PCR bank
set. However, as it appears not all hw implement those. Sad.
Let's add some minimal logic to auto-detect supported PCR banks: if
SHA256 is supported, use that. But if not, automatically fall back to
SHA1.
This then changes both the LUKS code, and the credentials code to
serialize the selected bank, along with the rest of the data in order to
make this robust.
This extends the LUK2 JSON metadata in a compatible way. The credentials
encryption format is modified in an incompatible way however, but given
that this is not part of any official release should be OK.
Fixes: #20134
Add support for systemd-tpm2 based LUKS2 device activation
via libcryptsetup plugin. This make the feature (tpm2 sealed
LUKS2 keyslot passphrase) usable from both systemd utilities
and cryptsetup cli.
The feature is configured via -Dlibcryptsetup-plugins combo
with default value set to 'auto'. It get's enabled automatically
when cryptsetup 2.4.0 or later is installed in build system.
