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
