linux-kernel - Re: [PATCH v8 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <uo2q3jxzcu3d4noiznxpw5woaclikmywyzi7yjlnpef3fdjt4e@idvs7tiv3znb>
Date: Wed, 12 Feb 2025 08:43:21 +0800
From: Coiby Xu <coxu@...hat.com>
To: Baoquan He <bhe@...hat.com>
Cc: akpm@...ux-foundation.org, kexec@...ts.infradead.org, 
	Ondrej Kozina <okozina@...hat.com>, Milan Broz <gmazyland@...il.com>, 
	Thomas Staudt <tstaudt@...ibm.com>, Daniel P . Berrangé <berrange@...hat.com>, 
	Kairui Song <ryncsn@...il.com>, Pingfan Liu <kernelfans@...il.com>, 
	Dave Young <dyoung@...hat.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Dave Hansen <dave.hansen@...el.com>, Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH v8 0/7] Support kdump with LUKS encryption by reusing
 LUKS volume keys

On Tue, Feb 11, 2025 at 06:25:18PM +0800, Baoquan He wrote:
>On 02/07/25 at 04:08pm, Coiby Xu wrote:
>> LUKS is the standard for Linux disk encryption, widely adopted by users,
>> and in some cases, such as Confidential VMs, it is a requirement. With
>> kdump enabled, when the first kernel crashes, the system can boot into
>> the kdump/crash kernel to dump the memory image (i.e., /proc/vmcore)
>> to a specified target. However, there are two challenges when dumping
>> vmcore to a LUKS-encrypted device:
>>
>>  - Kdump kernel may not be able to decrypt the LUKS partition. For some
>>    machines, a system administrator may not have a chance to enter the
>>    password to decrypt the device in kdump initramfs after the 1st kernel
>>    crashes; For cloud confidential VMs, depending on the policy the
>>    kdump kernel may not be able to unseal the keys with TPM and the
>>    console virtual keyboard is untrusted.
>>
>>  - LUKS2 by default use the memory-hard Argon2 key derivation function
>>    which is quite memory-consuming compared to the limited memory reserved
>>    for kdump. Take Fedora example, by default, only 256M is reserved for
>>    systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
>>    to be reserved for kdump. Note if the memory reserved for kdump can't
>>    be used by 1st kernel i.e. an user sees ~1300M memory missing in the
>>    1st kernel.
>>
>> Besides users (at least for Fedora) usually expect kdump to work out of
>> the box i.e. no manual password input or custom crashkernel value is
>> needed. And it doesn't make sense to derivate the keys again in kdump
>> kernel which seems to be redundant work.
>>
>> This patch set addresses the above issues by making the LUKS volume keys
>> persistent for kdump kernel with the help of cryptsetup's new APIs
>> (--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
>> the kdump copies of LUKS volume keys,
>>
>>  1. After the 1st kernel loads the initramfs during boot, systemd
>>     use an user-input passphrase to de-crypt the LUKS volume keys
>>     or TPM-sealed key and then save the volume keys to specified keyring
>>     (using the --link-vk-to-keyring API) and the key will expire within
>>     specified time.
>>
>>  2. A user space tool (kdump initramfs loader like kdump-utils) create
>>     key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
>>     the 1st kernel which keys are needed.
>>
>>  3. When the kdump initramfs is loaded by the kexec_file_load
>>     syscall, the 1st kernel will iterate created key items, save the
>>     keys to kdump reserved memory.
>>
>>  4. When the 1st kernel crashes and the kdump initramfs is booted, the
>>     kdump initramfs asks the kdump kernel to create a user key using the
>>     key stored in kdump reserved memory by writing yes to
>>     /sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
>>     device is unlocked with libcryptsetup's --volume-key-keyring API.
>>
>>  5. The system gets rebooted to the 1st kernel after dumping vmcore to
>>     the LUKS encrypted device is finished
>>
>> After libcryptsetup saving the LUKS volume keys to specified keyring,
>> whoever takes this should be responsible for the safety of these copies
>> of keys. The keys will be saved in the memory area exclusively reserved
>> for kdump where even the 1st kernel has no direct access. And further
>> more, two additional protections are added,
>>  - save the copy randomly in kdump reserved memory as suggested by Jan
>>  - clear the _PAGE_PRESENT flag of the page that stores the copy as
>>    suggested by Pingfan
>>
>> This patch set only supports x86. There will be patches to support other
>> architectures once this patch set gets merged.
>
>This v8 looks good to me, thanks for the great effort, Coiby.
>
>Acked-by: Baoquan He <bhe@...hat.com>

Great, thanks for reviewing and acknowledging the patch set!

-- 
Best regards,
Coiby