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