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

["Jan Sebastian Götte" <contact@jaseg.de>]

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.