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
