From: Baoquan He <baoquan.he@linux.dev>
To: "Jan Sebastian Götte" <linux@jaseg.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Dave Young <ruirui.yang@linux.dev>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Mimi Zohar <zohar@linux.ibm.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Coiby Xu <coxu@redhat.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kexec@lists.infradead.org, keyrings@vger.kernel.org,
linux-mm@kvack.org, linux-security-module@vger.kernel.org,
linux-integrity@vger.kernel.org
Subject: Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump
Date: Sat, 1 Aug 2026 22:03:22 +0800 [thread overview]
Message-ID: <am38qk60mpVFuJRi@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20260731154608.153258-1-linux@jaseg.de>
On 07/31/26 at 05:46pm, Jan Sebastian Götte wrote:
> I'm using linux on an embedded target in a Hardware Security Module-like
> application. One requirement is that I want the system to be able to
> quickly erase its memory when it detects physical tampering. I'm
> approaching that by using kdump to load into a small payload that
> instead of dumping RAM, erases RAM from start to end. However, writing
> all of RAM, especially on an embedded target, is rather slow. For this
> reason, I propose the mechanism in this patch series:
>
> Add CONFIG_CRASH_ZEROIZE (default off), which when enabled makes various
> subsystems handling secret data do a quick, targeted wipe of these
> secrets before kdump. This behavior might also be interesting in cases
> where you run a normal kdump kernel but you still want to keep things
> like fde crypto keys out of these dumps.
Please check below patchset, you both seem to have the similar
requirement. Please go there to discuss.
[RFC PATCH 0/4] panic: a pre kdump notifier list for hypervisor upcalls
Note that we usually dont' want to run a lot of work after panic and
before jumping into kdump kernel.
>
> CONFIG_CRASH_ZEROIZE is a best effort, defense in depth solution. There
> are circumstances, such as when a panic is triggered after memory
> corruption, or when a panic interrupts some operation that mutates data
> structures under locks, when the kernel cannot safely wipe some memory
> areas. The handlers proposed in this series will just print a warning
> and skip the affected areas in this case.
>
> This series introduces two handlers as a starting point: One for kernel
> keyrings, and one for secretmem. Future places where such handlers could
> be added would be for example drivers for crypto accelerators.
>
> The patch series applies on top of linux-next but should work on 7.0.0,
> too. I've tested the patches on a Arduino uno Q (Qualcomm QRB2210)
> embedded target.
>
> Jan Sebastian Götte (4):
> of/kexec: fix typo in comment (usable-memory-range)
> kexec: add CRASH_ZEROIZE to wipe secrets before kdump
> mm/secretmem: zeroize secret pages before kdump
> security/keys: zeroize key payloads before kdump
>
> drivers/of/kexec.c | 2 +-
> include/linux/crash_core.h | 5 +++
> include/linux/key-type.h | 9 ++++
> kernel/Kconfig.kexec | 8 ++++
> kernel/crash_core.c | 18 ++++++++
> mm/secretmem.c | 50 +++++++++++++++++++++++
> security/keys/big_key.c | 15 +++++++
> security/keys/encrypted-keys/encrypted.c | 12 ++++++
> security/keys/key.c | 44 ++++++++++++++++++++
> security/keys/trusted-keys/trusted_core.c | 14 +++++++
> security/keys/user_defined.c | 11 +++++
> 11 files changed, 187 insertions(+), 1 deletion(-)
>
> --
> 2.53.0
>
next parent reply other threads:[~2026-08-01 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260731154608.153258-1-linux@jaseg.de>
2026-08-01 14:03 ` Baoquan He [this message]
2026-08-01 16:31 ` [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump Jan Sebastian Götte
2026-08-02 5:08 ` Dave Young
2026-08-02 10:20 ` Jan Sebastian Götte
2026-08-03 12:12 ` Dave Young
2026-08-03 12:54 ` Jan Sebastian Götte
2026-08-03 9:59 ` David Howells
2026-08-03 12:00 ` Dave Young
2026-07-31 16:27 Jan Sebastian Götte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=am38qk60mpVFuJRi@MiWiFi-R3L-srv \
--to=baoquan.he@linux.dev \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=coxu@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux@jaseg.de \
--cc=pasha.tatashin@soleen.com \
--cc=paul@paul-moore.com \
--cc=pratyush@kernel.org \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=saravanak@kernel.org \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.