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: <20260114210859.GA3197242-robh@kernel.org>
Date: Wed, 14 Jan 2026 15:08:59 -0600
From: Rob Herring <robh@...nel.org>
To: Coiby Xu <coxu@...hat.com>
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 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.

Rob