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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLEsUV34tMZWSMc6w-xDV=M0JpOmS95TxrtbbBMRoD3Jw@mail.gmail.com>
Date: Tue, 6 Jan 2026 09:44:37 -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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ