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/kexec@xxxxxxxxxxxxxxxxxxxxxxx/thread/RTYJEQ4BV25JYVYJHTTPOK476FUEJOWW/) 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@%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@%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 _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
