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. Rob
