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

[Rob Herring]

On Wed, Jan 07, 2026 at 07:39:24PM +0800, Coiby Xu wrote:
> On Tue, Jan 06, 2026 at 09:44:37AM -0600, Rob Herring wrote:
> > On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu <coxu at redhat.com> wrote:
> > > 
> > > Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds
> > > LUKS-encrypted device dump target support to ARM64 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 add device tree property dmcryptkeys as similar to
> > > elfcorehdr to pass the memory address of the stored info of dm-crypt
> > > keys to the kdump kernel.
> > 
> > Is there not any security issue with putting the key into the DT? The
> > DT is provided to userspace. There's provisions already to not expose
> > "security-*" properties to userspace (see __of_add_property_sysfs).
> > Though I think that has a hole in that the FDT is also provided as-is.
> > However, I don't even know who or what uses these properties.
> > 
> > Rob
> 
> Hi Rob,
> 
> Thanks for raising the concern! If I understand DT correctly, this
> property is only accessible to the kexec'ed kdump kernel. A new DT is
> allocated and set up by of_kexec_alloc_and_setup_fdt. Btw, to be
> precise, it's putting the memory address where the key is stored but
> not the key itself into DT. The key is stored in the memory exclusively
> reserved for kdump. For more info on by who and how this property will
> used, I've created a dt-schema pull request as suggested by Krzysztof,
> https://github.com/devicetree-org/dt-schema/pull/181

Okay, that's a bit less sensitive. That still could expose a memory 
address to user space which has generally been locked down in recent 
years. Though I'm not sure we'd consider addresses of blobs passed by 
kexec sensitive or secure.

> 
> And yes, there is no need for even userspace of the kdump kernel to
> access it. So this idea of "security-*" properties/__of_add_property_sysfs
> seems desirable. Thanks for bringing it up! I'll give it a try.

Since it is just the memory address, kdump just moving the key would be 
sufficient. Or the property can be removed early on. I think we do that 
with kaslr seed IIRC.

Rob