From: Milan Broz <gmazyland@gmail.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>,
devel@lists.fedoraproject.org, kexec@lists.fedoraproject.org,
"systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>,
kasong@redhat.com, dm-crypt@saout.de
Subject: [dm-crypt] Re: Antw: [EXT] [systemd-devel] Kdump with full-disk LUKS encryption
Date: Tue, 20 Apr 2021 15:37:13 +0200 [thread overview]
Message-ID: <e44216e5-c94f-1c52-90fc-357b86962cdc@gmail.com> (raw)
In-Reply-To: <607E6F26020000A100040A30@gwsmtp.uni-regensburg.de>
On 20/04/2021 08:05, Ulrich Windl wrote:
>>>> Kairui Song <kasong@redhat.com> 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 -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de
next prev parent reply other threads:[~2021-04-20 13:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 10:00 [dm-crypt] Kdump with full-disk LUKS encryption Kairui Song
2021-04-20 6:05 ` [dm-crypt] Antw: [EXT] [systemd-devel] " Ulrich Windl
2021-04-20 13:37 ` Milan Broz [this message]
2021-04-20 7:54 ` [dm-crypt] " Milan Broz
2021-04-20 9:23 ` Kairui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e44216e5-c94f-1c52-90fc-357b86962cdc@gmail.com \
--to=gmazyland@gmail.com \
--cc=Ulrich.Windl@rz.uni-regensburg.de \
--cc=devel@lists.fedoraproject.org \
--cc=dm-crypt@saout.de \
--cc=kasong@redhat.com \
--cc=kexec@lists.fedoraproject.org \
--cc=systemd-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).