>>> Kairui Song <kasong@xxxxxxxxxx> schrieb am 19.04.2021 um 12:00 in Nachricht <CACPcB9e0=KYNc_-Bz5EnoHntKKXpurmXzu4e60J1sADQkizvsg@xxxxxxxxxxxxxx>: > 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). I'm not a LUKS specialist, but can't you use different KDFs in a different key slot? That may weaken the security of course. > > 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 > > _______________________________________________ > systemd‑devel mailing list > systemd‑devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
