On 9/28/26 19:17, 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 frmo start to end. However, writing > all of RAM, especially on an embedded target, is rather slow. For this > reason, I propose a new crash_memaction mechanism that lets the old > kernel indicate marked memory areas to the kdump kernel at page > granularity. > > I will be using this mechanism to indicate "secret" memory ranges for > early wiping by my kdump payload. After discussion with Baoquan He early > August, the patchset includes a second flag that can be used to indicate > "cache" memory that the kdump kernel may want to skip when creating the > dumpfile. > > The record is a bitmap with one bit per page, allocated at boot. It > reaches the kdump kernel as a PT_NOTE named MEMACTION. Marking is a > lock-free atomic bitmap update with no allocation, so it is safe in any > context.
This is all rather messy. So, in general, kdump has access to the memmap, and it can figure out certain things about pages to be dumped. That's what makedumpfile does. It can identify user pages, kernel pages, etc. If you could identify relevant pages through the memmap from the second kernel, you might be able to clean them. I'd assume you could identify secretmem pages that way. But all these madvise/mmap thingies are really not appropriate to reduce the zeroing. -- Cheers, David
