[systemd-devel] Antw: [EXT] Kdump with full-disk LUKS encryption

[Ulrich Windl]

>>> Kairui Song <kasong at redhat.com> schrieb am 19.04.2021 um 12:00 in
Nachricht
<CACPcB9e0=KYNc_-Bz5EnoHntKKXpurmXzu4e60J1sADQkizvsg at mail.gmail.com>:
> 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@lists.fedoraproject.org/

> 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 at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel