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 <[email protected]> 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
