Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Baoquan He]

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
> 

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Jan Sebastian Götte]

Hi there,

On 8/1/26 16:03, Baoquan He wrote:
> On 07/31/26 at 05:46pm, Jan Sebastian Götte wrote:
>> 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

Thank you for the pointer. That's indeed similar, but I think this 
patchset here makes sense as an independent patchset.

* The two notifier chains run at different points, and theirs runs 
inside panic independent of kdump. This one here has to be run after 
machine_crash_shutdown(), and so makes most sense inside 
__crash_kexec(). The wipe code in this patchset must be one of the last 
things to run before the kexec since the wiped data structures could 
easily lead to problems if something tried using them later.

* I think this patch series here is a bit cleaner. I don't think this 
needs a custom notifier implementation.

* Since there's lots of places that may need wiping after crash, I think 
it makes sense to have an explicit notifier list for that purpose, and 
to not mix these with other things like hypercalls. I think ordering is 
important here: The wiping should be the last thing before the kexec 
jump. Having it on a generic notifier chain risks that later, other 
callbacks get added that when interleaved could cause problems.

* Since a good fraction of users may not care about wiping secrets, I 
think it should be gated behind an explicit enable setting.

> Note that we usually dont' want to run a lot of work after panic and
> before jumping into kdump kernel.

I understand. For this reason, I think it's best to keep this 
default-off. As-is, the notifier list call is timed and on the (slow) 
ARM64 target I'm using, it takes about 3-5 ms to run. I took the "try 
lock, skip if locked" approach to keep the risk of this code crashing 
during panic minimal. In my application, the kdump payload is code that 
then does a full wipe, taking a couple hundred milliseconds.

Let me know what you think.

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Dave Young]

On 8/2/26 12:31 AM, Jan Sebastian Götte wrote:
> Hi there,
> 
> On 8/1/26 16:03, Baoquan He wrote:
>> On 07/31/26 at 05:46pm, Jan Sebastian Götte wrote:
>>> 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
> 
> Thank you for the pointer. That's indeed similar, but I think this patchset here makes sense as an independent patchset.
> 
> * The two notifier chains run at different points, and theirs runs inside panic independent of kdump. This one here has to be run after machine_crash_shutdown(), and so makes most sense inside __crash_kexec(). The wipe code in this patchset must be one of the last things to run before the kexec since the wiped data structures could easily lead to problems if something tried using them later.
> 
> * I think this patch series here is a bit cleaner. I don't think this needs a custom notifier implementation.
> 
> * Since there's lots of places that may need wiping after crash, I think it makes sense to have an explicit notifier list for that purpose, and to not mix these with other things like hypercalls. I think ordering is important here: The wiping should be the last thing before the kexec jump. Having it on a generic notifier chain risks that later, other callbacks get added that when interleaved could cause problems.
> 
> * Since a good fraction of users may not care about wiping secrets, I think it should be gated behind an explicit enable setting.
> 
>> Note that we usually dont' want to run a lot of work after panic and
>> before jumping into kdump kernel.
> 
> I understand. For this reason, I think it's best to keep this default-off. As-is, the notifier list call is timed and on the (slow) ARM64 target I'm using, it takes about 3-5 ms to run. I took the "try lock, skip if locked" approach to keep the risk of this code crashing during panic minimal. In my application, the kdump payload is code that then does a full wipe, taking a couple hundred milliseconds.

Not only about the time used, the panicked kernel is not reliable, any more extra logic can make it even not reliable, any pre-kdump extra logic is not a good idea unless it is a must to ensure kdump working.

Cleaning up secret data can be done with makedumpfile + eppic scripts (see the manual of makedumpfile), or it is even possible to do so in kdump kernel with Tao Liu's improvments for makedumpfile previously  (I don't know the status, probably dropped for the time being, but it is possible, cced him).

Thanks
Dave

> 
> Let me know what you think.

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Jan Sebastian Götte]

On 8/2/26 07:08, Dave Young wrote:
> On 8/2/26 12:31 AM, Jan Sebastian Götte wrote:
>> On 8/1/26 16:03, Baoquan He wrote:
>>> Note that we usually dont' want to run a lot of work after panic and
>>> before jumping into kdump kernel.
>>
>> I understand. For this reason, I think it's best to keep this default-off. As-is, the notifier list call is timed and on the (slow) ARM64 target I'm using, it takes about 3-5 ms to run. I took the "try lock, skip if locked" approach to keep the risk of this code crashing during panic minimal. In my application, the kdump payload is code that then does a full wipe, taking a couple hundred milliseconds.
> 
> Not only about the time used, the panicked kernel is not reliable, any more extra logic can make it even not reliable, any pre-kdump extra logic is not a good idea unless it is a must to ensure kdump working.
> 
> Cleaning up secret data can be done with makedumpfile + eppic scripts (see the manual of makedumpfile), or it is even possible to do so in kdump kernel with Tao Liu's improvments for makedumpfile previously  (I don't know the status, probably dropped for the time being, but it is possible, cced him).

Thank you for the pointer!

There's two scenarios worth considering. First, in the standard scenario 
where you enable this option, then drop into a standard kdump kernel, I 
don't think it makes a big difference *when* you do this cleanup since 
someone is going to have to dereference these pointers. IMHO a good 
reason to do it in the old kernel is that there, the code knows about 
the layout of all the data structures. To retroactively do this in the 
kdump kernel is much more complicated, since there you have to 
reconstruct the structure layouts from symbols or hardcoded struct 
layouts, and you have to keep this symbol/layout information perfectly 
in sync with the running kernel.

The second scenario is what I'm working on here: I'm not using a normal 
kdump kernel, but instead a custom payload that wipes all RAM from start 
to end. This payload will wipe all these keys too, but my critical 
concern is speed: On the embedded SoCs I'm targeting, the full memory 
wipe takes too long (hundreds of ms) for an HSM application, so I want 
to do a targeted wipe of just the keys first. The old kernel I think is 
the natural place to do this. Adding to that, in my scenario the most 
likely trigger of a panic is not something like memory corruption, but a 
trigger of the system's tamper alarms, which would leave the old kernel 
relatively stable during panic.

I can imagine several possible mitigations for the stability concerns 
beyond the default off config option:

* Since the wipe handlers are all really simple, it would be possible to 
manually guard every memory access there to ensure they can't fail and 
that they don't write to sensitive areas like the dump kernel or the 
remaining panic'ing stack. Doing that would only rely on information 
(more or less intact stack pointer, kdump kernel area boundaries) that 
would be necessary for kdump to succeed anyway.

* And/Or I could extend the patchset to include a mechanism similar to 
that in Bradley Morgan's patchset that catches segfaults during wipe, 
and then skips the handler causing the fault.

* A last option would be to have the alive kernel prepare some kind of 
"wipe this first" structure in its memory during normal operation that 
the dump kernel then can pick up to do the actual dirty work. I disfavor 
that since it adds double bookkeeping to a lot of places, some of which 
could be performance critical.

I've also picked up that I should remove the timing logic since that 
could cause instability.

Thanks,
Jan Sebastian

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Dave Young]

On 8/2/26 6:20 PM, Jan Sebastian Götte wrote:
> On 8/2/26 07:08, Dave Young wrote:
>> On 8/2/26 12:31 AM, Jan Sebastian Götte wrote:
>>> On 8/1/26 16:03, Baoquan He wrote:
>>>> Note that we usually dont' want to run a lot of work after panic and
>>>> before jumping into kdump kernel.
>>>
>>> I understand. For this reason, I think it's best to keep this default-off. As-is, the notifier list call is timed and on the (slow) ARM64 target I'm using, it takes about 3-5 ms to run. I took the "try lock, skip if locked" approach to keep the risk of this code crashing during panic minimal. In my application, the kdump payload is code that then does a full wipe, taking a couple hundred milliseconds.
>>
>> Not only about the time used, the panicked kernel is not reliable, any more extra logic can make it even not reliable, any pre-kdump extra logic is not a good idea unless it is a must to ensure kdump working.
>>
>> Cleaning up secret data can be done with makedumpfile + eppic scripts (see the manual of makedumpfile), or it is even possible to do so in kdump kernel with Tao Liu's improvments for makedumpfile previously  (I don't know the status, probably dropped for the time being, but it is possible, cced him).
> 
> Thank you for the pointer!
> 
> There's two scenarios worth considering. First, in the standard scenario where you enable this option, then drop into a standard kdump kernel, I don't think it makes a big difference *when* you do this cleanup since someone is going to have to dereference these pointers. IMHO a good reason to do it in the old kernel is that there, the code knows about the layout of all the data structures. To retroactively do this in the kdump kernel is much more complicated, since there you have to reconstruct the structure layouts from symbols or hardcoded struct layouts, and you have to keep this symbol/layout information perfectly in sync with the running kernel.


I know that this is the usual reason people want to do things in 1st
kernel :)   Like the crash_kexec_post_notifiers which was introduced for
people to use at their own risk.  Is it doable for your case to use
crash_kexec_post_notifiers?


> 
> The second scenario is what I'm working on here: I'm not using a normal kdump kernel, but instead a custom payload that wipes all RAM from start to end. This payload will wipe all these keys too, but my critical concern is speed: On the embedded SoCs I'm targeting, the full memory wipe takes too long (hundreds of ms) for an HSM application, so I want to do a targeted wipe of just the keys first. The old kernel I think is the natural place to do this. Adding to that, in my scenario the most likely trigger of a panic is not something like memory corruption, but a trigger of the system's tamper alarms, which would leave the old kernel relatively stable during panic.
> 
> I can imagine several possible mitigations for the stability concerns beyond the default off config option:
> 
> * Since the wipe handlers are all really simple, it would be possible to manually guard every memory access there to ensure they can't fail and that they don't write to sensitive areas like the dump kernel or the remaining panic'ing stack. Doing that would only rely on information (more or less intact stack pointer, kdump kernel area boundaries) that would be necessary for kdump to succeed anyway.
> 
> * And/Or I could extend the patchset to include a mechanism similar to that in Bradley Morgan's patchset that catches segfaults during wipe, and then skips the handler causing the fault.
> 
> * A last option would be to have the alive kernel prepare some kind of "wipe this first" structure in its memory during normal operation that the dump kernel then can pick up to do the actual dirty work. I disfavor that since it adds double bookkeeping to a lot of places, some of which could be performance critical.
> 
> I've also picked up that I should remove the timing logic since that could cause instability.
> 
> Thanks,
> Jan Sebastian

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Jan Sebastian Götte]

On 8/3/26 14:12, Dave Young wrote:
> On 8/2/26 6:20 PM, Jan Sebastian Götte wrote:
>> On 8/2/26 07:08, Dave Young wrote:
>>> On 8/2/26 12:31 AM, Jan Sebastian Götte wrote:
>>>> On 8/1/26 16:03, Baoquan He wrote:
>>>>> Note that we usually dont' want to run a lot of work after panic and
>>>>> before jumping into kdump kernel.
>>>>
>>>> I understand. For this reason, I think it's best to keep this default-off. As-is, the notifier list call is timed and on the (slow) ARM64 target I'm using, it takes about 3-5 ms to run. I took the "try lock, skip if locked" approach to keep the risk of this code crashing during panic minimal. In my application, the kdump payload is code that then does a full wipe, taking a couple hundred milliseconds.
>>>
>>> Not only about the time used, the panicked kernel is not reliable, any more extra logic can make it even not reliable, any pre-kdump extra logic is not a good idea unless it is a must to ensure kdump working.
>>>
>>> Cleaning up secret data can be done with makedumpfile + eppic scripts (see the manual of makedumpfile), or it is even possible to do so in kdump kernel with Tao Liu's improvments for makedumpfile previously  (I don't know the status, probably dropped for the time being, but it is possible, cced him).
>>
>> Thank you for the pointer!
>>
>> There's two scenarios worth considering. First, in the standard scenario where you enable this option, then drop into a standard kdump kernel, I don't think it makes a big difference *when* you do this cleanup since someone is going to have to dereference these pointers. IMHO a good reason to do it in the old kernel is that there, the code knows about the layout of all the data structures. To retroactively do this in the kdump kernel is much more complicated, since there you have to reconstruct the structure layouts from symbols or hardcoded struct layouts, and you have to keep this symbol/layout information perfectly in sync with the running kernel.
> 
> I know that this is the usual reason people want to do things in 1st
> kernel :)   Like the crash_kexec_post_notifiers which was introduced for
> people to use at their own risk.  Is it doable for your case to use
> crash_kexec_post_notifiers?

I think there's a few reasons why crash_kexec_post_notifiers isn't what 
we want here:

1. Enabling/disabling just the key wipe notifiers scattered around the 
kernel becomes a bit ugly when they're mixed into the same notifier list.
2. The key wipe should run after other notifiers because by definition 
it will corrupt data structures so future operations like any crypto 
operations will fail in interesting ways. Having two separate notifier 
chains is an easy way to separate them.
3. For my use case, the stability argument is exactly why I want to run 
only the wipe, but not crash_kexec_post_notifiers. There are many things 
in crash_kexec_post_notifiers. They take precious time, and they 
themselves can cause instability. For example, the remoteproc panic 
notifier can (intentionally) wait up to several hundred milliseconds, 
which is too long in my use case.

Thanks,
Jan Sebastian

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[David Howells]

Dave Young <ruirui.yang@linux.dev> wrote:

> Cleaning up secret data can be done with makedumpfile + eppic scripts (see
> the manual of makedumpfile), or it is even possible to do so in kdump kernel
> with Tao Liu's improvments for makedumpfile previously (I don't know the
> status, probably dropped for the time being, but it is possible, cced him).

Does this represent a leak of the secrets?  Also do governmental
standardisation bodies have opinions on what constitutes a leak?

David

Re: [PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Dave Young]

On 8/3/26 5:59 PM, David Howells wrote:
> Dave Young <ruirui.yang@linux.dev> wrote:
> 
>> Cleaning up secret data can be done with makedumpfile + eppic scripts (see
>> the manual of makedumpfile), or it is even possible to do so in kdump kernel
>> with Tao Liu's improvments for makedumpfile previously (I don't know the
>> status, probably dropped for the time being, but it is possible, cced him).
> 
> Does this represent a leak of the secrets?  Also do governmental
> standardisation bodies have opinions on what constitutes a leak?

It depends, for the crash case I'm not against to clear sensitive data, the
concern is to avoid extra complexity of logic pre-kdump.   Which
government?  Sorry I can not answer here.  

> 
> David
> 

Re: [PATCH 2/4] kexec: add CRASH_ZEROIZE to wipe secrets before kdump

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Calling ktime_get() in the panic path after machine_crash_shutdown() can permanently hang the crash transition, preventing kdump from working.
- [Low] Conditionally exposing a raw notifier list without an API wrapper forces subsystems to use #ifdef and risks build breaks.

Pre-existing issues:
- [High] ktime_get_real_seconds() in crash_save_vmcoreinfo() deadlocks on 32-bit systems if the local CPU interrupted a timekeeping update.
--

--- Patch [2]: [PATCH 2/4] kexec: add CRASH_ZEROIZE to wipe secrets before kdump ---
commit e20f9219f7505b929366dca07a7894f6b666a4b5
Author: Jan Sebastian Götte <linux@jaseg.de>
Subject: kexec: add CRASH_ZEROIZE to wipe secrets before kdump

This patch adds a new CRASH_ZEROIZE opt-in atomic notifier chain to scrub
sensitive secrets before launching a kdump kernel. The zeroization runs late
in __crash_kexec() after other CPUs are shut down.

> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index c1dee3f971a91..685ed8926966d 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h

[ ... ]

> @@ -34,6 +35,10 @@ static inline void arch_kexec_protect_crashkres(void) { }
>  static inline void arch_kexec_unprotect_crashkres(void) { }
>  #endif
>  
> +#ifdef CONFIG_CRASH_ZEROIZE
> +extern struct atomic_notifier_head crash_zeroize_notifier_list;
> +#endif
> +

[Severity: Low]
Does exposing this raw notifier list conditionally force subsystems to use
ifdefs when registering callbacks?

Usually, kernel APIs provide a wrapper (like
register_crash_zeroize_notifier()) with a static inline no-op for disabled
configurations to avoid breaking the build.

>  #ifndef arch_crash_handle_hotplug_event
>  static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }
>  #endif

[ ... ]

> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 4f21fc3b108b8..49192b20dc9f6 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c

[ ... ]

> @@ -33,6 +34,22 @@
>  /* Per cpu memory for storing cpu states in case of system crash. */
>  note_buf_t __percpu *crash_notes;
>  
> +#ifdef CONFIG_CRASH_ZEROIZE
> +ATOMIC_NOTIFIER_HEAD(crash_zeroize_notifier_list);
> +EXPORT_SYMBOL_GPL(crash_zeroize_notifier_list);
> +
> +static void crash_zeroize(void)
> +{
> +	ktime_t zeroize_start = ktime_get();

[Severity: High]
Can calling ktime_get() cause a deadlock here and on completion?

Since crash_zeroize() runs after machine_crash_shutdown() has forcefully
halted all other CPUs, if any of those halted CPUs were in the middle of a
timekeeping update and held the tk_core.seq write lock, this loop in
ktime_get():

kernel/time/timekeeping.c:ktime_get() {
    ...
    do {
        seq = read_seqcount_begin(&tk_core.seq);
        ...
    } while (read_seqcount_retry(&tk_core.seq, seq));
    ...
}

would spin indefinitely, preventing the kdump kernel from booting. Should this
use a lockless accessor like ktime_get_mono_fast_ns() instead?

> +
> +	pr_info("Wiping sensitive secrets...\n");
> +	atomic_notifier_call_chain(&crash_zeroize_notifier_list, 0, NULL);
> +	pr_info("Done in %lld us\n", ktime_us_delta(ktime_get(), zeroize_start));
> +}
> +#else
> +static inline void crash_zeroize(void) { }
> +#endif /* CONFIG_CRASH_ZEROIZE */
> +

[ ... ]

> @@ -142,6 +159,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)
>  			crash_save_vmcoreinfo();

[Severity: High]
This is a pre-existing issue, but can crash_save_vmcoreinfo() also deadlock
during a panic?

If a local CPU interrupts a timekeeping update (holding the timekeeper write
seqcount) via an NMI or hardirq, and then triggers a panic, it will call
crash_save_vmcoreinfo() which eventually calls ktime_get_real_seconds():

kernel/vmcore_info.c:crash_save_vmcoreinfo() {
    ...
    vmcoreinfo_append_str("CRASHTIME=%lld\n", ktime_get_real_seconds());
    ...
}

On 32-bit platforms, this falls back to reading tk_core.seq, which the local
CPU already holds for write, leading to an infinite spin and preventing the
crash dump.

>  			machine_crash_shutdown(&fixed_regs);
>  			crash_cma_clear_pending_dma();
>  			crash_zeroize();
>  			machine_kexec(kexec_crash_image);
>  		}
>  		kexec_unlock();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731154608.153258-1-linux@jaseg.de?part=2

Re: [PATCH 3/4] mm/secretmem: zeroize secret pages before kdump

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Deadlock in panic path due to `free_folio` attempting to acquire blocking locks.
- [High] Zeroization loop silently fails because it iterates over an empty `sb->s_inodes` list.
- [Low] Missing `spin_unlock` for `s_inode_list_lock` on the success path.
--

--- Patch [3]: [PATCH 3/4] mm/secretmem: zeroize secret pages before kdump ---
commit 2960931b04ec8dddbd17c954634f6a26336377a1
Author: Jan Sebastian Götte <linux@jaseg.de>

mm/secretmem: zeroize secret pages before kdump

This commit adds a crash notifier to zeroize secretmem folios before a kdump
kernel is kexec'ed. It iterates over the page cache without taking the i_pages
lock, as zeroization runs after other CPUs have been stopped.

> diff --git a/mm/secretmem.c b/mm/secretmem.c
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c

[ ... ]

> @@ -187,6 +189,50 @@ static const struct inode_operations secretmem_iops = {
>  
>  static struct vfsmount *secretmem_mnt;
>  
> +#ifdef CONFIG_CRASH_ZEROIZE
> +/* Called far into vpanic from crash_core.c with other CPUs stopped and
> + * preemption disabled
> + */
> +static int secretmem_crash_zeroize(struct notifier_block *nb, unsigned long
> +		action, void *data)
> +{
> +	struct super_block *sb;
> +	struct inode *inode;
> +
> +	if (!secretmem_mnt)
> +		return NOTIFY_DONE;
> +	sb = secretmem_mnt->mnt_sb;
> +
> +	/* If the list was modified in the exact moment we panic'ed, it might be
> +	 * in an inconsistent state that would be unsafe to iterate. If we can't
> +	 * get the lock, too bad, that's all we can do here.
> +	 */
> +	if (!spin_trylock(&sb->s_inode_list_lock)) {
> +		pr_crit("crash_zeroize: can't acquire secretmem superblock lock.\n"
> +			 "crash_zeroize: skipping zeroizing secretmem.\n");
> +		return NOTIFY_DONE;
> +	}
> +
> +	list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {

[Severity: High]
Does this loop actually iterate over any secretmem files?

In secretmem_file_create(), the inode is allocated via
anon_inode_make_secure_inode(). That function uses new_inode_pseudo(), which
intentionally skips adding the inode to the superblock's s_inodes list.

Because of this, won't sb->s_inodes be empty (or contain only the root inode),
causing the zeroization process to silently skip all secretmem folios?

> +		XA_STATE(xas, &inode->i_mapping->i_pages, 0);
> +		struct folio *folio;
> +
> +		/* no need for locks if we're burning down the house :) */
> +		xas_for_each(&xas, folio, ULONG_MAX) {
> +			if (xas_retry(&xas, folio) || xa_is_value(folio))
> +				continue;
> +			inode->i_mapping->a_ops->free_folio(folio);

[Severity: High]
Can calling free_folio() here cause a deadlock during a kernel panic?

The free_folio callback points to secretmem_free_folio(), which eventually
calls set_direct_map_default_noflush() on the folio's head page.

On architectures like x86, set_direct_map_default_noflush() resolves to
__set_pages_p(), which acquires cpa_lock (via spin_lock(&cpa_lock)). If a
secondary CPU was stopped by an NMI while holding cpa_lock, won't this cause
the panicking CPU to spin indefinitely, preventing the crash kernel from
loading?

> +		}
> +	}
> +	/* off to kexec()! */
> +	return NOTIFY_DONE;

[Severity: Low]
Is there a missing spin_unlock(&sb->s_inode_list_lock) before returning on
this success path?

Even though the system is in a terminal state, leaving the lock acquired via
spin_trylock() permanently held could unbalance preemption or confuse lock
debugging if it runs after this point.

> +}
> +
> +static struct notifier_block secretmem_zeroize_nb = {
> +	.notifier_call = secretmem_crash_zeroize
> +};
> +#endif /* CONFIG_CRASH_ZEROIZE */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731154608.153258-1-linux@jaseg.de?part=3

Re: [PATCH 4/4] security/keys: zeroize key payloads before kdump

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Key payloads detached during update or revocation and pending RCU destruction are skipped, leaking secrets into the crash dump.
- [High] Lockless reading of `big_key` payloads during non-atomic updates causes torn reads, leading to massive out-of-bounds writes during panic zeroization.
--

--- Patch [4]: [PATCH 4/4] security/keys: zeroize key payloads before kdump ---
commit 5ba36d14be79dc23bd8b584d1f1a143c55ab30ba
Author: Jan Sebastian Götte <linux@jaseg.de>

security/keys: zeroize key payloads before kdump

When CONFIG_CRASH_ZEROIZE is set, try to erase key payloads on panic
before jumping to the kdump kernel. Implement the zeroize op for
various key types.

> diff --git a/security/keys/big_key.c b/security/keys/big_key.c
> index 268f702df380e..ad8537dda70fa 100644
> --- a/security/keys/big_key.c
> +++ b/security/keys/big_key.c
[ ... ]
> @@ -279,6 +282,18 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)
>  	return ret;
>  }
>  
> +static void big_key_zeroize(struct key *key)
> +{
> +	struct big_key_payload *payload = to_big_key_payload(key->payload);
> +
> +	if (payload->data) {
> +		if (payload->length > BIG_KEY_FILE_THRESHOLD)
> +			memzero_explicit(payload->data, CHACHA20POLY1305_KEY_SIZE);
> +		else
> +			memzero_explicit(payload->data, payload->length);

[Severity: High]
Does this code risk an out-of-bounds write if a panic happens during a key
update?

If big_key_update() is called, it updates the payload via
generic_key_instantiate(), which writes the new buffer pointer to data[0] and
then updates the length in data[3]:

security/keys/key.c:generic_key_instantiate() {
    rcu_assign_keypointer(key, prep->payload.data[0]);
    key->payload.data[1] = prep->payload.data[1];
    key->payload.data[2] = prep->payload.data[2];
    key->payload.data[3] = prep->payload.data[3];
}

If a panic stops the writer CPU after rcu_assign_keypointer() but before the
length is updated, could big_key_zeroize() read the new, smaller buffer pointer
but use the old, larger length, causing memzero_explicit() to corrupt memory
during the crash dump process?

> +	}
> +}
> +
>  /*
>   * Register key type
>   */
[ ... ]
> diff --git a/security/keys/key.c b/security/keys/key.c
> index 091ee084bc300..4f0e8e579cebd 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
[ ... ]
> @@ -1268,6 +1269,44 @@ void unregister_key_type(struct key_type *ktype)
>  }
>  EXPORT_SYMBOL(unregister_key_type);
>  
> +#ifdef CONFIG_CRASH_ZEROIZE
> +/* Called far into vpanic from crash_core.c with other CPUs stopped and
> + * preemption disabled
> + */
> +static int key_crash_zeroize(struct notifier_block *nb, unsigned long action,
> +		void *data)
> +{
> +	struct rb_node *node;
> +
> +	/* If we can't acquire the lock, the rbtree might be in an inconsistent
> +	 * state. That's all we can do then, as there's no point to waiting
> +	 * at this stage.
> +	 */
> +	if (!spin_trylock(&key_serial_lock)) {
> +		pr_crit("crash_zeroize: can't acquire key_serial_lock. skipping keyrings.\n");
> +		return NOTIFY_DONE;
> +	}
> +
> +	for (node = rb_first(&key_serial_tree); node; node = rb_next(node)) {

[Severity: High]
Does this loop miss key payloads that have been detached but not yet freed?

When a key is updated, the old payload is displaced and queued for RCU free:

security/keys/user_defined.c:user_update() {
    ...
    rcu_assign_keypointer(key, prep->payload.data[0]);
    prep->payload.data[0] = NULL;
    
    if (zap)
        call_rcu(&zap->rcu, user_free_payload_rcu);
}

If a panic occurs before the RCU grace period completes, the old payload
remains in memory but is no longer reachable via the active keys in
key_serial_tree. Will these displaced payloads containing secrets be leaked
into the crash dump since they are skipped by this zeroization loop?

> +		struct key *key = rb_entry(node, struct key, serial_node);
> +
> +		if (key->type == &key_type_keyring ||
> +		    key->state == KEY_IS_UNINSTANTIATED)
> +			continue;
> +
> +		/* custom zeroize since free'ing isn't safe at this point */
> +		if (key->type->zeroize)
> +			key->type->zeroize(key);
> +	}
> +	/* off to kexec()! */
> +	return NOTIFY_DONE;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731154608.153258-1-linux@jaseg.de?part=4

[PATCH 0/4] CRASH_ZEROIZE: Wipe secrets before kdump

[Jan Sebastian Götte]

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 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