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

[Coiby Xu]

On Wed, Jan 14, 2026 at 03:08:59PM -0600, Rob Herring wrote:
>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.

A security-* property is still exposed to user space. I think simply
removing the property is an elegant solution! It's also much simpler
than moving the key. I did a test and somehow wiping the old memory
in read_from_oldmem_iter made it fail to read the keys. So I'll apply
your suggestion of removing the property to next version. Thanks!

>
>Rob
>

-- 
Best regards,
Coiby