[PATCH v2 01/13] kexec: add CRASH_WIPE_SECRETS to wipe secrets before kdump

Jan Sebastian Götte contact at jaseg.de
Tue Aug 18 02:03:19 PDT 2026


On 8/17/26 10:25, Baoquan He wrote:
> On 08/17/26 at 03:38pm, Baoquan He wrote:
>> On 08/16/26 at 02:13pm, Lukas Wunner wrote:
>>> On Wed, Aug 12, 2026 at 12:08:39PM +0200, Jan Sebastian Götte wrote:
>>>> I can imagine one alternative way to approach this, tell me what you think:
>>>> Instead of registering wipe handlers that memzero places on panic, I could
>>>> put an optional registry of (addr, len) descriptors into crashkernel memory
>>>> that the original kernel populates with the PAs of buffers to clear ahead of
>>>> time. Then the kdump kernel could do the actual memzero. This would remove
>>>> all code from the actual kdump path here. The registry could be made
>>>> per-core to avoid locks.
> 
> If this has to be done in kernel, your (addr, len) registry idea is a
> better direction, and we can make it a bit more general.
> 
> Instead of a secrets-only wipe registry, consider a small "crash memory
> region" table with an action per entry:
> 
> enum crash_region_action {
>      CRASH_REG_WIPE,   /* memzero, then dump normally (leave zeros) */
>      CRASH_REG_SKIP,   /* do not include in the vmcore at all */
> };
> 
> struct crash_region {
>      phys_addr_t addr;
>      size_t      len;
>      enum crash_region_action action;
> };
> 
> void crash_reg_add(phys_addr_t addr, size_t len,
>                     enum crash_region_action action);
> void crash_reg_del(phys_addr_t addr, size_t len);
> 
> Two actions because the use cases differ:
> 
> - WIPE is what you need: zero the secret,
> - SKIP covers things people do not want in the dump at all
>     — Registering as SKIP reduce dump size. I have been considering how
>       to shrink vmcore size on some big system with huge memory, the
>       vmcore size usually is several or tens of GB.
> 
> If this is OK to you, you can start a regiestry table
> infrastructure with wiping secrets, we can add SKIP later and plus some
> driver used memory.
> 
> I am not sure if it's satisfactory, but you can give it a shot to show
> what it looks like.
I think that's a good idea. I'll post a patch adding that registry this 
or next week.

Thanks,
Jan




More information about the linux-afs mailing list