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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aW4Jq9on_4a5o5o7@Rk>
Date: Mon, 19 Jan 2026 18:57:23 +0800
From: Coiby Xu <coxu@...hat.com>
To: Rob Herring <robh@...nel.org>
Cc: kexec@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, 
	Arnaud Lefebvre <arnaud.lefebvre@...ver-cloud.com>, Baoquan he <bhe@...hat.com>, Dave Young <dyoung@...hat.com>, 
	Kairui Song <ryncsn@...il.com>, Pingfan Liu <kernelfans@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, Saravana Kannan <saravanak@...gle.com>, 
	open list <linux-kernel@...r.kernel.org>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" <devicetree@...r.kernel.org>
Subject: Re: [PATCH] arm64/kdump: pass dm-crypt keys to kdump kernel

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@...hat.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