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

On 20/04/2021 08:05, Ulrich Windl wrote:
>>>> Kairui Song <[email protected]> schrieb am 19.04.2021 um 12:00 in
> Nachricht
> <CACPcB9e0=KYNc_-Bz5EnoHntKKXpurmXzu4e60J1sADQkizvsg@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?

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 -- [email protected]
To unsubscribe send an email to [email protected]