On 8/12/26 11:30, Baoquan He wrote:
On 08/11/26 at 07:52pm, Jan Sebastian Götte wrote: .....snip...@@ -142,6 +170,7 @@ void __noclone __crash_kexec(struct pt_regs *regs) crash_save_vmcoreinfo(); machine_crash_shutdown(&fixed_regs); crash_cma_clear_pending_dma(); + crash_wipe_secrets();I remember when crash_cma added this, we argued a lot about the risk, finally it's added in with an added note to tell it's an opt-in feature and risky. I don't know if it opens a Pandora box, I think anything wanted being here need prove anything else has been tried, and the thing is very very important. If we don't guard the door well, one day one guy cold come and said I need ask Oracle database to do some transactions before juming into kdump kernel because the actions will save billions of dollar.
I see your point.
And what does security people say about this wiping? Is it very important information and wiping is mandotary? There's no any other way to wipe it or pollute it, no way in kdump kernel?
I'm doing both - my kdump kernel does a linear memzero of all of DRAM. However, that's too slow - it takes several hundred milliseconds, and I want these cryptographic keys gone within no more than 10 ms.
Doing this in the original kernel is cleanest I think, because to do a targeted erase in the kdump kernel, that kernel would have to know all the original kernel's symbols, and it would have to forensically reconstruct it's memory content similar to the crash utility. I think that's too complex and error-prone to do in this use case.
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.
I noticed it's happening on en embedded target, is it possible you do this on your embedded kernel tree, but not mainline tree?
I could keep it in a vendor tree, but I think the functionality is useful beyond my particular use case.
