[PATCH] powerpc/kdump: pass dm-crypt keys to kdump kernel

Coiby Xu coxu at redhat.com
Tue Jan 6 17:26:45 AEDT 2026


On Thu, Jan 01, 2026 at 08:36:09PM +0530, Sourabh Jain wrote:
>
>
>On 26/12/25 19:36, Coiby Xu wrote:
>>Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds
>>LUKS-encrypted device dump target support to PowerPC 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.
>>
>>1st kernel will build up the kernel command parameter dmcryptkeys as
>>similar to elfcorehdr to pass the memory address of the stored info of
>>dm-crypt keys to the kdump kernel.
>>
>>[1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
>>
>>Cc: Thomas Staudt <tstaudt at de.ibm.com>
>>Cc: Arnaud Lefebvre <arnaud.lefebvre at clever-cloud.com>
>>Cc: Baoquan he <bhe at redhat.com>
>>Cc: Dave Young <dyoung at redhat.com>
>>Cc: Kairui Song <ryncsn at gmail.com>
>>Cc: Pingfan Liu <kernelfans at gmail.com>
>>Cc: Andrew Morton <akpm at linux-foundation.org>
>>Signed-off-by: Coiby Xu <coxu at redhat.com>
>>---
>>  arch/powerpc/include/asm/kexec.h |  3 ++-
>>  arch/powerpc/kexec/elf_64.c      | 26 +++++++++++++++++++++++++-
>>  arch/powerpc/kexec/file_load.c   | 19 +++++++++++--------
>>  3 files changed, 38 insertions(+), 10 deletions(-)
>>
>>diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
>>index bd4a6c42a5f3..f3d098d543b4 100644
>>--- a/arch/powerpc/include/asm/kexec.h
>>+++ b/arch/powerpc/include/asm/kexec.h
>>@@ -80,7 +80,8 @@ struct kimage_arch {
>>  };
>>  char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
>>-			  unsigned long cmdline_len);
>>+			  unsigned long cmdline_len,
>>+			  char *name, unsigned long addr);
>>  int setup_purgatory(struct kimage *image, const void *slave_code,
>>  		    const void *fdt, unsigned long kernel_load_addr,
>>  		    unsigned long fdt_load_addr);
>>diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>>index 5d6d616404cf..57cb3361d91b 100644
>>--- a/arch/powerpc/kexec/elf_64.c
>>+++ b/arch/powerpc/kexec/elf_64.c
>>@@ -81,13 +81,37 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>  		/* Setup cmdline for kdump kernel case */
>>  		modified_cmdline = setup_kdump_cmdline(image, cmdline,
>>-						       cmdline_len);
>>+						       cmdline_len,
>>+						       "elfcorehdr",
>>+						       image->elf_load_addr);
>>  		if (!modified_cmdline) {
>>  			pr_err("Setting up cmdline for kdump kernel failed\n");
>>  			ret = -EINVAL;
>>  			goto out;
>>  		}
>>  		cmdline = modified_cmdline;
>>+		cmdline_len = strlen(cmdline) + 1;
>>+
>>+		ret = crash_load_dm_crypt_keys(image);
>>+		if (ret == -ENOENT) {
>>+			kexec_dprintk("No dm crypt key to load\n");
>>+		} else if (ret) {
>>+			pr_err("Failed to load dm crypt keys\n");
>>+			return ERR_PTR(ret);
>>+		}
>>+
>>+		if (image->dm_crypt_keys_addr != 0) {
>>+			modified_cmdline = setup_kdump_cmdline(image, cmdline,
>>+							       cmdline_len,
>>+							       "dmcryptkeys",
>>+							       image->dm_crypt_keys_addr);
>>+			if (!modified_cmdline) {
>>+				pr_err("Setting up cmdline for kdump kernel failed\n");
>>+				ret = -EINVAL;
>>+				goto out;
>>+			}
>>+			cmdline = modified_cmdline;
>>+		}
>>  	}
>>  	if (initrd != NULL) {
>>diff --git a/arch/powerpc/kexec/file_load.c b/arch/powerpc/kexec/file_load.c
>>index 4284f76cbef5..e1c08050286d 100644
>>--- a/arch/powerpc/kexec/file_load.c
>>+++ b/arch/powerpc/kexec/file_load.c
>>@@ -23,38 +23,41 @@
>>  #define SLAVE_CODE_SIZE		256	/* First 0x100 bytes */
>>  /**
>>- * setup_kdump_cmdline - Prepend "elfcorehdr=<addr> " to command line
>>+ * setup_kdump_cmdline - Prepend "<name>=<addr> " to command line
>>   *                       of kdump kernel for exporting the core.
>>   * @image:               Kexec image
>>   * @cmdline:             Command line parameters to update.
>>   * @cmdline_len:         Length of the cmdline parameters.
>>+ * @name:                Name e.g elfcorehdr.
>>+ * @addr:                Memory address.
>>   *
>>   * kdump segment must be setup before calling this function.
>>   *
>>   * Returns new cmdline buffer for kdump kernel on success, NULL otherwise.
>>   */
>>  char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
>>-			  unsigned long cmdline_len)
>>+			  unsigned long cmdline_len,
>>+			  char *name, unsigned long addr)
>>  {
>>-	int elfcorehdr_strlen;
>>+	unsigned long parameter_len;
>>  	char *cmdline_ptr;
>>  	cmdline_ptr = kzalloc(COMMAND_LINE_SIZE, GFP_KERNEL);
>>  	if (!cmdline_ptr)
>>  		return NULL;
>>-	elfcorehdr_strlen = sprintf(cmdline_ptr, "elfcorehdr=0x%lx ",
>>-				    image->elf_load_addr);
>>+	parameter_len = sprintf(cmdline_ptr, "%s=0x%lx ", name, addr);
>>-	if (elfcorehdr_strlen + cmdline_len > COMMAND_LINE_SIZE) {
>>-		pr_err("Appending elfcorehdr=<addr> exceeds cmdline size\n");
>>+	if (parameter_len + cmdline_len > COMMAND_LINE_SIZE) {
>>+		pr_err("Appending %s=<addr> exceeds cmdline size\n", name);
>>  		kfree(cmdline_ptr);
>>  		return NULL;
>>  	}
>>-	memcpy(cmdline_ptr + elfcorehdr_strlen, cmdline, cmdline_len);
>>+	memcpy(cmdline_ptr + parameter_len, cmdline, cmdline_len);
>>  	// Ensure it's nul terminated
>>  	cmdline_ptr[COMMAND_LINE_SIZE - 1] = '\0';
>>+	kfree(cmdline);
>
>When setup_kdump_cmdline() is called for elfcorehdr, cmdline holds the
>same pointer as image->cmdline_buf. Freeing it here may therefore
>cause issues, right?

Yes, you are right, I'll drop the above kfree in next version.

>
>Currently, image->cmdline_buf is not used after calling the
>architecture-specific load function (elf64_load on powerpc).
>However, kimage_file_post_load_cleanup() later calls kfree() on
>the same address.

I missed kimage_file_post_load_cleanup. Thanks for pointing it out!


-- 
Best regards,
Coiby



More information about the Linuxppc-dev mailing list