I've been trying to come up with an easy way to implement #2776, and from what I can tell converting an unencrypted block device into a luks volume is not easy to do, so it's probably not something we'd want to automate / encourage users to do. When implementing immutable stuff, I saw a comment in the systemd-repart manpage: ``` --key-file= Takes a file system path. .... If this switch is not specified, the empty key (i.e. zero length key) is used. This behaviour is useful for setting up encrypted partitions during early first boot that receive their user-supplied password only in a later setup step. ``` ## tldr This gave me an idea that, after a bit of research, seems like something we could implement. The tl;dr is we *always* put the rootfs on a luks volume, and if `pmb install --fde` isn't specified then we set the key/passphrase to an empty one. Then we have a UI that allows users to set a passphrase, and we run `cryptsetup reencrypt` on the volume to change the volume key and reencrypt it. Users who don't care about FDE will still have an encrypted volume but with an empyt passphrase and (in the case of prebuilt images) a shared volume key. This is obviously "bad" but it's no worse than having an unencrypted rootfs/data partition. ## details There are 2 effectively groups of users: 1) users who don't care about fde 2) users who care about fde 3) users who start off in group, then realize they're in group 2, and will be considered as part of group 2 below :grinning: ### creating the volume and unlocking it on boot What I'm proposing is that all rootfs, regardless of `--fde parameter` are places on a luks2 volume with empty passphrase, created during image build. `--fde` can be used to set the passphrase to a custom one when building an image, or maybe that option just goes away(?) Effectively, what we'd do is something like this when creating the luks volume for the rootfs: ``` $ echo '' | cryptsetup luksFormat --key-file=- /dev/sda2` ``` Then in the initramfs, we would try to open it with an empty key and fallback to unl0kr if that fails (because the user changed the passphrase and we need to prompt): ``` echo '' | cryptsetup luksOpen --key-file=- /dev/sda2 root || do_unl0kr ``` ### changing the passphrase A UI (unl0kr? f0rmz? something new in the rootfs? gnome-initial-setup?) would offer an interface for users to set a new passphrase. Then we'd need to essentially do this to add the new passphrase, remove the old passphrase, and then trigger a reencrypt to change the volume key: ``` echo 'supersecretpassfromuser' | cryptsetup luksAddKey --key-file=- /dev/sda2 echo '' | cryptsetup luksRemoveKey --key-file=- /dev/sda2 cryptsetup reencrypt /dev/sda2 ``` Re-encryption runs transparently in the background, and can run "online". We will also need to retrigger a reencryption in the initramfs after opening the volume on the off-chance that the reencryption was interrupted (e.g. by power loss, shutdown, or something like that). There's a param we can pass to reencrypt to trigger the reencrypt **only** if there is a previous attempt to resume: ``` cryptsetup reencrypt --resume-only /dev/sda2 || true ``` - `--resume-only` called unconditionally in initramfs after every `open` - Returns 0 if interrupted reencryption exists (resumes it) - Returns non-zero if no reencryption in progress (ignored via `|| true`) - Interrupted reencryption (poweroff, crash, whatever) auto-resumes on next boot - Reencryption runs online ## considerations (To be expanded if others raise points) - There's probably a performance impact with always using luks, especially on slower devices. Maybe we can have a deviceinfo variable to allow those devices to opt out of having this enabled by default. Any UI to allow setting a passphrase would have to detect if the rootfs is **not** on a luks volume and show a message that it's not possible to enable encryption on this install without reinstalling. Otherwise, I've personally been using FDE on everything I own for years and not once do I recall a situation where I thought "wow this disk is slow, it's probably because I have FDE enabled!" 😅