On 8/11/26 20:20, Eric Biggers wrote:
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.
These crash wipe code paths are less critical than places where you'd
use memzero_explicit or kfree_sensitive. They are "only" a defense in
depth / hardening measure. For most of these, if the crash happens at
the exact time when data structures are being modified or when things
are being intialized/deinitialized, they can skip things so they can
never be 100% reliable anyway.
It's not realistic to clean *all* sensitive data in the first place,
since that would include plaintext as well, which would mean cleaning
the entire page cache which would be too complex, take too long, and
destroy forensic evidence that people might want to keep intact for
regular kdump uses.
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.
I'm sure there's always more. In my particular application, I'm using
this not for complete coverage (for that I have another full memory wipe
afterwards), but for speed - I want the obviously sensitive stuff like
keys gone as fast as possible, with the full wipe cleaning up whatever
the fast wipe here missed.
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.
I'm open to whittling down the scope of this series. In my use case I
need at least secretmem as well as dm-crypt, which then pulls in the
crypto tfm stuff. Personally, I could live without the other bits, I
just thought they'd be easy enough to include.
- Jan
