Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jun 2005 21:50:26 +0200
From:      Erik Trulsson <ertr1013@student.uu.se>
To:        Mike Hunter <mhunter@ack.berkeley.edu>
Cc:        Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>, freebsd-hackers@freebsd.org
Subject:   Re: unitialized memory is all zeros...why not garbage instead?
Message-ID:  <20050613195026.GA90010@falcon.midgard.homeip.net>
In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu>
References:  <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 13, 2005 at 12:31:50PM -0700, Mike Hunter wrote:
> On Jun 11, "Dag-Erling Smrgrav" wrote:
> 
> > Mike Hunter <mhunter@ack.berkeley.edu> writes:
> > > I have a feeling that I'm missing something really obvious, but I'm having
> > > trouble understanding why the following program:
> > > [...]
> > > Never prints anything but "0"'s.
> > 
> > Because the kernel always hands processes pre-zeroed pages.
> > 
> > > I ran less up to my hw.physmem by feeding it /dev/random and watching
> > > top, and then ran the program, so I "know" there was tons of non-zero
> > > bits in memory.
> > 
> > If your program had been able to see leftovers from less in its own
> > address space, we'd have a huge security hole on our hands.
> > 
> > > I'm curious because I am worried about information leaks between processes
> > > on the same machine...did somebody decide to solve this problem while I
> > > wasn't paying attention?  :)
> > 
> > It's always been this way.
> 
> Thanks for setting me straight.  I guess it wasn't this way on DOS where I
> first learned C++ and I've assumed garbage ever since :)

That is a good assumption.  It is not true everywhere, but it rarely
hurts being on the safe side.

> 
> Is the pre-zeroing of malloc'd memory documented somewhere?  By my reading 
> of the malloc manapge...
> 
>      The calloc() function allocates space for number objects, each size 
>      bytes in length.  The result is identical to calling malloc() with an
>      argument of ``number * size'', with the exception that the allocated 
>      memory is explicitly initialized to zero bytes.
> 
> ...it seems like it's saying that malloc (as opposed to calloc) is NOT
> pre-zeroed.  Is there a different document I should be reading?

Note that this pre-zeroing is not done by malloc, but is done by the
kernel before it hands over memory to a process.  Memory is not necessarily
returned to the system when free() is called, but is often retained
within the process and reused by the next malloc().


This means that if you have a sequence like the following:

foo=malloc(1234);
bar=malloc(1234);
/* do something that fills the memory that foo points to with garbage
*/
free(foo);
baz=malloc(1234);

Then there is no guarantees whatsoever that baz will not point to
garbage.  The memory that malloc() returns in the third call to
malloc() will most likely be the same as that previously pointed to by
foo and will still be filled with garbage.

If your program needs zeroed memory you should use calloc() or do the
zeroing yourself - malloc doesn't do it.

What is guaranteed is that any garbage in the memory returned by
malloc() will have been created by the same process, so that
information is not leaked from another process in this way.


In short memory from malloc() may or may not be pre-zeroed, but it is
not a security problem in either case.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050613195026.GA90010>