Re: Zeroed pages returned for heap

[Richard B. Johnson]

On Wed, 8 Jun 2005, Nagendra Singh Tomar wrote:

> On Tue, 7 Jun 2005, Peter Staubach wrote:
>
> > Nagendra Singh Tomar wrote:
> >
> > >Hi all,
> > >	The short version first.
> > >Is it OK for an application (a C library implementing malloc/calloc is
> > >also an application) to assume that the pages returned by the OS for heap
> > >allocation (either directly thru brk() or thru mmap(MAP_ANONYMOUS)) will
> > >be zero filled.
> > >
> >
> > An application which makes assumptions about the contents of newly allocated
> > memory would seem to be making very dangerous assumptions.
>
> Thats what glibc does. Ulrich confirmed that. I would say thats not a bad
> optimization on glibc's part as it does not really make sense to zero out
> a memory again in user space if we know for sure that new heap memory that
> kernel hands over to us will be zeroed. I'm not sure though whether this
> is a documented kernel ABI.
>
> >
> > Ignoring that, would it not be considered to be a security violation to hand
> > pieces of memory to applications without erasing the old contents of the
> > pages?
>
> I understand that for a desktop/server running Linux but not for an
> embedded box where all the applications that run on the box is controlled
> by you.
>
> Thanx,
> Tomar

The user code can't assume anything about any memory allocated
by malloc(). The first time a buffer is allocated, it may be
zero-filled because of the zeroed pages allocated by the kernel
when the new break address is set. After that, all bets are off
because once you free a buffer and allocate another one, it
will probably contain data from malloc()'s previous allocation.

Even the very first time malloc() returns a pointer, doesn't
guarantee that the memory will all be cleared. This is because
many malloc()s use just-obtained memory (via brk) to do some
house-keeping which may result in some "strange" numbers in
the memory at some places.

It is extremely bad coding practice to assume a buffer is
zero filled when writing user-mode code. That's why we have
calloc().


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/