I was just wondering if it is possible to tell Linux/Ubuntu to overwrite freed memory with zeroes before letting the next application allocate it?

If not, why isn't this possible? I know that security critical programs will (probably) overwrite memory themselves before freeing it, but my guess is, that if you have enough RAM available it wouldn't even slow down the system. At least as long as the free() call isn't blocked.

Any thoughts?

  • 2
    a) "At least as long as the free() call isn't blocked." ... then how can you be sure when the system is finished writing zeroes? b) Why not just memset() the memory before freeing, and ensure it yourself? – muru Jan 14 '16 at 16:37
  • If the worry is security, why not overwrite RAM like you overwrite deleted sectors on a hard drive, with multiple passes of pseudorandom line noise? Because in most cases, it is an unnecessary use of CPU. This is why security programs explicitly do so and non-security programs skip this step (in the interests of application optimization). The question is: what is more important? Paranoia or performance. – Aren Jan 14 '16 at 19:57
  • @muru the kernel obviously does that on Ubuntu as Colin stated in his answer. I just tried a little program on Ubuntu 15.04 and the RAM actually is just zeroes! Of course you are right with the memset() thing. – Chris K. Jan 15 '16 at 10:35
  • @Aren it does not noticeably cost performance if this happens after the process has ended - unless of course another process immediately wants to have exactly that page(s) – Chris K. Jan 15 '16 at 10:37
  • @ChrisK. Noticeable might be debatable if you are using an older, low-performance system. I do accept your point, though, as RAM writes are orders of magnitude faster than HDD writes. – Aren Jan 15 '16 at 19:52

When a process calls free() it does not return the memory immediately back to system, instead it returns it back to the heap owned by that process. The heap either uses anonymous memory mapping for large chunks or sbrk() to shrink or grow the heap. Memory from the heap is returned back to the system when it is unmap'd or the heap shrinks with sbrk(). At this point pages can be re-used by other processes and when they are re-used they are always zero'd before the process can access it. [1]

memory allocations such as malloc don't zero memory when it is free'd back to the heap because of performance issues. Normally, the best practice for sensitive data is to be zero'd before it free'ing it. However, I guess you want to enforce this police for all memory being free'd during a processes' life time. glibc 2.4 and upwards has a MALLOC_PERTURB_ environment option that when set to non-zero value will initialize the memory to the compliment of the value when the memory is allocated and when it is released with free(). The downside to this is that it may trigger bugs in code that erroneously rely on the memory to be normally initialized to zero on allocation.

To use MALLOC_PERTURB_, e.g. to set it to a random value..

export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

and run your code.

[1] Well almost. mmap() using MAP_UNINITIALIZED and a kernel configured with CONFIG_MMAP_ALLOW_UNINITIALIZED allows non-zeroing of memory, but this is never allowed on Ubuntu.

  • 1
    This seems to be an Ubuntu thing, can that be? I once tested it on another System and made the mistake to expect having zeros the first time I malloc (was just learning C at the time). THANK YOU anyways for your answer! Very interesting! – Chris K. Jan 15 '16 at 10:31
  • 1
    malloc() does not initialise the data it returns and one should never expect that it does. However, if you are allocating data that comes from a newly anonymously mmap()'d region or from expanding the heap via brk() then the kernel will return zero'd data. If you want zero'd data, use calloc() – Colin Ian King Jan 15 '16 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.