Subject: Re: [PATCH v4 2/2] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel

From: Coiby Xu <[email-masked]>
Date: Thu, 12 Feb 2026 10:01:58 +0800

On Wed, Feb 11, 2026 at 10:55:17AM +0100, Christophe Leroy (CS GROUP) wrote:
>
>
>Le 11/02/2026 à 09:24, Coiby Xu a écrit :
>>CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
>>device dump target by addressing two challenges [1],
>>  - 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
>>
>>  - LUKS2 by default use the memory-hard Argon2 key derivation function
>>    which is quite memory-consuming compared to the limited memory reserved
>>    for kdump.
>>
>>To also enable this feature for ARM64 and PowerPC, we only need to add
>
>What do you want to say exactly with 'only' ?

Hi Christophe,

Thanks for raising the question! To clarify, CONFIG_CRASH_DM_CRYPT
provides the framework to address these challenges for LUKS-encrypted
dump target. Since the heavy lifting is handled in the arch-independent
code, we only need to...

If it looks good to you, I'll rephrase it as "To also enable this
feature for ARM64 and PowerPC, the missing piece is to let the kdump
kernel know where to find the dm-crypt keys which are randomly stored in
memory reserved for kdump. I'll introduce a new device tree property
dmcryptkeys ...".

>
>>a device tree property dmcryptkeys [2] as similar to elfcorehdr to pass
>>the memory address of the stored info of dm-crypt keys to the kdump
>>kernel. Since this property is only needed by the kdump kernel, it won't
>>be exposed to user space.
>>
>>[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20250502011246.99238-1-coxu%40redhat.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C0aa5f3b34d694b23b0cc08de6946f66c%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639063950684962054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8uCc%2Bg6YNojymf8UpZhmJY19vpWXJCC9KIf3qMyQ3dI%3D&reserved=0
>>[2] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdevicetree-org%2Fdt-schema%2Fpull%2F181&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C0aa5f3b34d694b23b0cc08de6946f66c%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639063950684987003%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1s5NPHgF1LsXdrDXBhawduFXOqnHPlkbohQHHvolLw4%3D&reserved=0
>>
>>Cc: Arnaud Lefebvre <[email-masked]>
>>Cc: Baoquan he <[email-masked]>
>>Cc: Dave Young <[email-masked]>
>>Cc: Kairui Song <[email-masked]>
>>Cc: Pingfan Liu <[email-masked]>
>>Cc: Andrew Morton <[email-masked]>
>>Cc: Krzysztof Kozlowski <[email-masked]>
>>Cc: Rob Herring <[email-masked]>
>>Cc: Thomas Staudt <[email-masked]>
>>Cc: Sourabh Jain <[email-masked]>
>>Cc: Will Deacon <[email-masked]>
>>Signed-off-by: Coiby Xu <[email-masked]>
>>---
>>  arch/arm64/kernel/machine_kexec_file.c |  4 ++++
>>  arch/powerpc/kexec/elf_64.c            |  4 ++++
>>  drivers/of/fdt.c                       | 21 +++++++++++++++++++++
>>  drivers/of/kexec.c                     | 19 +++++++++++++++++++
>>  4 files changed, 48 insertions(+)
>>
>>diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>index 331646d667b9..2967e4aff807 100644
>>--- a/drivers/of/fdt.c
>>+++ b/drivers/of/fdt.c
>>@@ -866,6 +866,26 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
>>  		 elfcorehdr_addr, elfcorehdr_size);
>>  }
>>+static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
>>+{
>>+	const char *prop_name = "linux,dmcryptkeys";
>>+	const __be32 *prop;
>>+
>>+	if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
>>+		return;
>>+
>>+	pr_debug("Looking for dmcryptkeys property... ");
>>+
>>+	prop = of_get_flat_dt_prop(node, prop_name, NULL);
>>+	if (!prop)
>>+		return;
>>+
>>+	dm_crypt_keys_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
>>+
>>+	/* Property only accessible to crash dump kernel */
>>+	fdt_delprop(initial_boot_params, node, prop_name);
>
>Shouldn't this property be deleted regardless of whether kernel is 
>built with CONFIG_CRASH_DM_CRYPT or without ?

This property will be created only if 1) CONFIG_CRASH_DM_CRYPT is
enabled and 2) the dump target is LUKS-encrypted. So there is no need to
delete it if it doesn't exist at all.

>
>>+}
>>+
>>  static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
>>  /*
>>@@ -1097,6 +1117,7 @@ int __init early_init_dt_scan_chosen(char *cmdline)
>>  	early_init_dt_check_for_initrd(node);
>>  	early_init_dt_check_for_elfcorehdr(node);
>>+	early_init_dt_check_for_dmcryptkeys(node);
>>  	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
>>  	if (rng_seed && l > 0) {
>

-- 
Best regards,
Coiby