On 20/04/2021 08:05, Ulrich Windl wrote: >>>> 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? Yes, you can (for LUKS2). There are also priorities, so you can configure "admin" keyslot that is never used unless explicitly specified. It can use different PBKDF and/or cost parameters. But this is not a solution for the mentioned problem - they have to work with arbitrary devices. Milan p.s. Some lists on cc rejects replies without subscription, so do not be surprised if you see only some replies. _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
