Re: [PATCH v2 00/13] CRASH_WIPE_SECRETS: Wipe secrets before kdump (was: CRASH_ZEROIZE)

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Aug 11, 2026 at 07:52:49PM +0200, 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.
> 
> 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 handlers for the major locations I found where
> having this sort of thing makes sense. Notable omissions right now are
> the Ceph and CIFS subsystems. I have WIP patches for these, but since I
> can't easily test them right now, I omitted them from this patch set for
> now. Currently included locations are:
> 
> * various key types in security/keys
> * rxrpc
> * fscrypt
> * dm-crypt
> * crypto tfm instances
> * secretmem (which I'm going to start using in my application)
> 
> I've verified this patch series on an ARM64 target using the helper code
> at https://codeberg.org/yasec/crash-wipe-test . This code stuffs the
> affected kernel subsystems with keys and secret data, then crashes the
> system, takes a RAM dump and verifies the dump is clean of secrets. Note
> that the helper code is partially LLM-generated, so read with care. It
> passes a positive control test with the config option disabled.
> 
> 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,
> ARM64) embedded target.

Can we not?  It's already hard enough to zeroize keys and data at the
normal end of their lifetime in the kernel: that's something that is
always a struggle, with fix patches regularly going by for many years
and many subsystems never fixed at all.  If we can barely even do that,
we aren't going to be able to correctly and completely implement and
maintain separate zeroization code for every kernel subsystem that runs
only on kernel panics and has special constraints, like not being able
to take locks.

This is never going to be done either, with the scope always wanting to
grow to include other keys and data.  You may think this series covers
"almost everything" but it's actually not even close.

Could you perhaps narrow the scope to one or two things that actually
are useful and can reasonably be supported for the application?  For
example, secretmem seems to be the only thing you mentioned that you're
actually planning to use.

- Eric