I believe that the Linux kernel allocates a zero-page in the page table when a
first-use (read) page fault occurs, and the zero-page is in fact zeroed out.
Since Linux is copy-on-write, when a write occurs to an address that maps
somewhere in that zero-page, a new page is allocated, the zero-page is copied
to it and the write applied, and the page table is updated.

So the short answer is that, no, I don't believe there is any way for another
process's memory to accidentally bleed into the memory accessed by the
heartbleed vulnerability.  If recently free()d memory was likely to show up
un-zeroed in another process's address space, we'd have enough concern about
data leaks that it would end up being rolled into free() to auto-zero each
page, since even in non-sensitive circumstances, you don't want one user to be
able to run a simple program to sniff for other users' documents that were just
in memory because they had it open in an editor...

 -Craig

On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote:
> Does heartbleed allow one to read (discarded, freed) physical memory 
> containing data from the OS and/or other processes in linux?
> 
> A friend and I were discussing this. If the memory management is "lazy" 
> (doesn't clear on page allocation/free), and if processes don't clear their 
> own memory, I wondered if heartbleed would expose anything. My friend thinks 
> "modern" operating systems clear memory to prevent inter-process data 
> leakage. Of course, I agree that this is security goodness, but I wonder if, 
> in the name of performance, this is "optional".
> 
> I'm poking around in linux memory management code in between other tasks, but 
> I'll bet somebody here knows the answer. Anyone?
> 
> 
> 
> _______________________________________________
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to