Wiping RAM before shutdown, How does Linux allocate memory?

Question

I know that many people think that wiping the RAM at shutdown is fairly pointless, I've done a fair bit of research on the benefits and drawbacks (and if it is really worth it). So in the nicest politest possible way... please no comments such as "Why do you want to wipe the Ram, its pointless"

I tried to DD /dev/mem and as expected DD threw up an error and the kernel warned that DD tried to access memory between 101000 and 101200. So my question is... How is memory allocated in Linux and more precisely, would any personal information exist between addresses 101000 and 101200 or is it totally reserved/protected for the kernel?

Thanks in advance

Tom

Answer 1

Since you provided no details I am assuming you are using quite recent kernel version running on x86.

Linux documentation provides physical memory layout after boot. You can see there that kernel is loaded at address 0x100000. That means in the region you are asking about (0x101000 - 0x101200) there is only kernel code.

Physical memory is allocated in pages using binary buddy allocator. It is described in much more details here.

However, wiping physical memory using anything except kernel code is impossible and may be dangerous (corruption of data on disks). If you really want to wipe RAM at shutdown I would suggest hacking the kernel.

Answer 2

In order to wipe physical memory to the best of your ability (you mentioned dd so we are talking about an userland solution!), it is sufficient to create an anonymous mapping the same size as the installed RAM¹ and to touch every page by writing a single byte (or any other amount) to one address inside each page.

This will cause a page fault and trigger a copy-on-write operation on the zero page for every page in your mapping that you touch, which will either commit an already zeroed page or zero an unused non-zeroed physical page of memory -- until there are none left, at which point your process will be killed by the OOM killer (or will receive SIGBUS, depending which one hits your process first).
If you want it to be somewhat "cleaner" (that is, without OOM killer), you need to stop before touching the last page, obviously. But in general, this is all it takes.

You will not be able to wipe all physical pages like this, but there really is no way of doing that with a user process (not without swap, and not in a deterministic way). Pages that are committed by other processes or pages that belong to the kernel can't be overwritten with this approach, at least not reliably (since there is no swap, these can't be swapped out, though you might be lucky and have OOM kill other processes instead of yours).
You cannot in general overwrite physical memory in a 100% reliable way unless you replace the running kernel.

If you want to be super "thorough", then your only option is to write code as it can be found e.g. in memtest_x86, which you invoke from kernel mode, replace the running kernel and overwrite raw physical memory "the hard way", much like memtest_x86 does, too.

But then, if you go the ultra-paranoia route, don't forget to clear GPU memory and wipe hard disk caches and network card memory as well...

---

¹ Actually, you would have to create a mapping the size of the maximum commit size -- but you stated that there is no swap, so "size of RAM" will do. Seeing how modern disk drives do extensive wear-levelling, overwriting swap wouldn't help an awful lot anyway, but at least you could guarantee that you are hitting all RAM pages if you commit up to the maximum commit size.