This commit adds support for disabling the read and write
workqueues with the new crypttab options no-read-workqueue
and no-write-workqueue. These correspond to the cryptsetup
options --perf-no_read_workqueue and --perf-no_write_workqueue
respectively.
Optionally, embedd PKCS#11 token URI and encrypted key in LUKS2 JSON
metadata header. That way it becomes very easy to unlock properly set up
PKCS#11-enabled LUKS2 volumes, a simple /etc/crypttab line like the
following suffices:
mytest /dev/disk/by-partuuid/41c1df55-e628-4dbb-8492-bc69d81e172e - pkcs11-uri=auto
Such a line declares that unlocking via PKCS#11 shall be attempted, and
the token URI and the encrypted key shall be read from the LUKS2 header.
An external key file for the encrypted PKCS#11 key is hence no longer
necessary, nor is specifying the precise URI to use.
It's highly confusing to reference the command line parameters via
argv[] indexes. Let's clean this up, and introduce properly named local
variables that make this easier to follow.
No actualy code changes, just some renaming of variables.
Let's move the 3rd way how cryptsetup acquires key files to
read_file_full() too.
Since load_key_file()'s raison d'etre now is just the search path logic,
let's rename the function to find_key_file().
Previously, we'd load the file with libcryptsetup's calls. Let's do that
in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET,
i.e. read in keys via AF_UNIX sockets, so that people can plug key
providers into our logic.
This provides functionality similar to Debian's keyscript= crypttab
option (see → #3007), as it allows key scripts to be run as socket
activated services, that have stdout connected to the activated socket.
In contrast to traditional keyscript= support this logic runs stuff out
of process however, which is beneficial, since it allows sandboxing and
similar.
This reverts commit 6c5496c492.
sysinit.target is shared between the initrd and the host system. Pulling in
initrd-cryptsetup.target into sysinit.target causes the following warning at
boot:
Oct 27 10:42:30 workstation-uefi systemd[1]: initrd-cryptsetup.target: Starting requested but asserts failed.
Oct 27 10:42:30 workstation-uefi systemd[1]: Assertion failed for initrd-cryptsetup.target.
For encrypted block devices that we need to unlock from the initramfs,
we currently rely on dracut shipping `cryptsetup.target`. This works,
but doesn't cover the case where the encrypted block device requires
networking (i.e. the `remote-cryptsetup.target` version). That target
however is traditionally dynamically enabled.
Instead, let's rework things here by adding a `initrd-cryptsetup.target`
specifically for initramfs encrypted block device setup. This plays the
role of both `cryptsetup.target` and `remote-cryptsetup.target` in the
initramfs.
Then, adapt `systemd-cryptsetup-generator` to hook all generated
services to this new unit when running from the initrd. This is
analogous to `systemd-fstab-generator` hooking all mounts to
`initrd-fs.target`, regardless of whether they're network-backed or not.
Adds support for LUKS detached header device on kernel
command line. It's introduced via extension to existing
luks.options 'header=' argument beyond colon (see examples
below). If LUKS header device is specified it's expected
to contain filesystem with LUKS header image on a path
specified in the first part of header specification.
The second parameter 'luks.data' specifies LUKS data device
supposed to be paired with detached LUKS header (note that
encrypted LUKS data device with detached header is unrecognisable
by standard blkid probe).
This adds support for LUKS encrypted rootfs partition with
detached header. It can also be used for initializing online LUKS2
encryption of data device.
Examples:
luks.data=<luks_uuid>=/dev/sdz
luks.data=<luks_uuid>=/dev/vg/lv
luks.data=<luks_uuid>=/dev/mapper/lv
luks.data=<luks_uuid>=PARTUUID=<part_uuid>
luks.data=<luks_uuid>=PARTLABEL=<part_uuid>
luks.options=<luks_uuid>=header=/header/path:UUID=<fs_uuid>
luks.options=<luks_uuid>=header=/header/path:PARTUUID=<part_uuid>
luks.options=<luks_uuid>=header=/header/path:PARTLABEL=<part_label>
luks.options=<luks_uuid>=header=/header/path:LABEL=<fs_label>
luks.options=<luks_uuid>=header=/header/path:/dev/sdx
luks.options=<luks_uuid>=header=/header/path:/dev/vg/lv
The '/header/path' is considered to be relative location within
filesystem residing on the header device specified beyond colon
character
Fixes#17035. We use "," as the separator between arguments in fstab and crypttab
options field, but the kernel started using "," within arguments. Users will need
to escape those nested commas.
`startswith` already returns the string with the prefix skipped, so we
can simplify this further and avoid using a magic value.
Noticed in passing.
Co-authored-by: Lennart Poettering <lennart@poettering.net>
Right now, we always say `/etc/crypttab` even if the source was fully
derived from the kargs.
Let's match what `systemd-fstab-generator` does and use `/proc/cmdline`
when that's the case.
Previously we would call umount from ExecStartPost= of
systemd-cryptsetup instance in order to get rid of the keydev
mount (i.e. filesystem containing keyfile). Let's generate unit to
handle umount. Making this symmetrical (both mount and umount of keydev
are handled by units) fixes the problem with lingering keydev mounts.
Motivation for the change is the issue where keydev mount would stay
around even if device was successfully unlocked and mount is no longer
needed. That could happen previously because when generator options are
not prefixed with "rd." we run generators twice (e.g. rd.luks.key=...).
In such case disk is unlocked in initramfs phase of boot (assuming the
initrd image contains the generator and is able to handle unlocking of
LUKS devices). After switchroot we however enqueue start job for
systemd-cryptsetup instance (because units are regenerated second time)
and that pulls in its dependencies into transaction. Later the main
systemd-cryptsetup unit not actually started since it is already active
and has RemainaAfterExit=yes. Nevertheless, dependencies get activated
and keydev mount is attached again. Because previously we called umount
from ExecStartPost= of systemd-cryptsetup instance the umount is not
called second time and keydev filesystem stays lingering.
"crypt-util.c" is such a generic name, let's avoid that, in particular
as libc's/libcrypt's crypt() function is so generically named too that
one might thing this is about that. Let's hence be more precise, and
make clear that this is about cryptsetup, and nothing else.
We already had cryptsetup-util.[ch] in src/cryptsetup/ doing keyfile
management. To avoid the needless confusion, let's rename that file to
cryptsetup-keyfile.[ch].
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
This doesn't fix anything IRL, but is a bit cleaner, since it makes sure
that arg_type is properly passed to crypt_load() in all cases.
We actually never set arg_type to CRYPT_LUKS2, which is why this wasn't
noticed before, but theoretically this might change one day, and
existing comments suggest it as possible value for arg_type, hence let's
process it properly.
let's do automatic discovery only for our native LUKS/LUKS2 headers,
since they are Linux stuff, and let's require that BitLocker to be
requested explicitly.
This makes sure cryptsetup without either "luks" nor "bitlk" in the
option string will work. Right now it would fail because we'd load the
superblock once with luks and once with bitlk and one of them would
necessarily fail.
Follow-up for #15979
This adds a new switch try-empty-password. If set and none of PKCS#11 or
key files work, it is attempted to unlock the volume with an empty
password, before the user is asked for a password.
Usecase: an installer generates an OS image on one system, which is the
booted up for the first time in a possibly different system. The image
is encrypted using a random volume key, but an empty password. A tool
that runs on first boot then queries the user for a password to set or
enrols the volume in the TPM, removing the empty password. (Of course, in
such a scenario it is important to never reuse the installer image on
multiple systems as they all will have the same volume key, but that's a
different question.)
Let's make loading of keys a bit more automatic and define a common
place where key files can be placed. Specifically, whenever a volume of
name "foo" is attempted, search for a key file in
/etc/cryptsetup-keys.d/foo.key and /run/cryptsetup-keys.d/foo.key,
unless a key file is declared explicitly.
With this scheme we have a simple discovery in place that should make it
more straightfoward wher to place keys, and requires no explicit
configuration to be used.
Luca Boccassi