Kdump with full-disk LUKS encryption

[Kairui Song]

Hi all,

I'm currently trying to add kdump support for systemd with full-disk
LUKS encryption. vmcores contain sensitive data so they should also be
protected, and network dumps sometimes are not available. So kdump has
to open the LUKS encrypted device in the kdump environment.

I'm using systemd/dracut, my work machine is running Fedora 34, and
there are several problems I'm trying to solve:
1. Users have to input the password in the kdump kernel environment.
But users often don't have shell access to the kdump environment.
(headless server, graphic card not working after kexec, both are very
common)
2. LUKS2 prefers Argon2 as the key derivation function, designed to
use a lot of memory. kdump is expected to use a minimal amount of
memory. Users will have to reserve a huge amount of memory for kdump
to work (eg. 1G reserve for kdump with 4G total memory which is not
reasonable).

To fix these problems, I tried to pass the master key to the second
kernel directly via initramfs. Kdump will modify the initramfs in
ramfs to include the key, kexec_load it, and never write to any actual
back storage. This worked with old LUKS configurations.

But LUKS2/cryptsetup now stores the key in the kernel keyring by
default. The key is accessible from userspace.

Users can enter the password to start kdump manually and then it will
work, but usually people expect kdump service to start automatically.

(WIP patch series:
https://lists.fedoraproject.org/archives/list/[e-mail].o...)

I've several ideas about how to improve it but not sure which one is
better, and if this is a good idea after all:
1. Simply introduce a config to let systemd-cryptsetup disable kernel
keyring on setup, there is currently no such option.

2. If we can let the key stay in userspace for a little longer, eg.
for systems booted with dracut/systemd, when
systemd-cryptsetup(a)%s.service opens the crypt device, keep the key in
dm-crypt. And later when services like kdump have finished loading,
cryptsetup can refresh the device and store the key in the kernel
keyring again.

3. Let kdump use some custom helper/service to load all needed
resources in the early initrd boot stage, prior to
systemd-cryptsetup(a)%s.service. It will ask the password / parse the
keyfile and load kdump, then provide info for systemd-cryptsetup or
just do the setup. Or maybe let systemd-cryptsetup support some kind
of "plugins" so other tools can use it.

4. A better and safer solution seems to keep a consistent key ring
between kexec boots but also more complex and difficult as different
arch implements kexec differently.

Any suggestions are welcomed!

--
Best Regards,
Kairui Song