Zeroed pages returned for heap

Zeroed pages returned for heap

[Nagendra Singh Tomar]

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. 

Now a lengthier version.

Linux zero fills all anonymous pages on allocation. This is _required_ for 
the C program BSS sections but _not_ _really_ required for heap pages. For 
heap pages the kernel zero fills them to avoid leaking any important 
information to users. On my target platform (Xscale) the memory access is 
such a big evil that I am constantly thinking of ways to avoid touching 
the damned memory as much as possible without any adverse effect on the 
kernel and applications behaviour. 
	One such way which I want to exploit is to not zero fill the heap 
pages (since mine is an embedded hardware, I do not care much abt leaking 
information out to users), since profiling has shown that the 
xscale_mc_clear_user_page function is taking lots of CPU time. When I 
implement that I see that few applications namely gcc and awk break. It 
seems that either the application or the C library is assuming about the 
pages returned by brk()/MAP_ANON, probably to improve calloc() efficiency 
( I'm not 100% sure on that as I've not yet looked at the code).
For testing I implemented this on x86 first and could boot the complete 
kernel and was able to start X, only that gcc used to crash.

I'll highly appreciate any informative views on this.

Thanx,
Tomar



-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.

Re: Zeroed pages returned for heap

[Ulrich Drepper]

On 6/6/05, Nagendra Singh Tomar <nagendra_tomar@adaptec.com> wrote:
> 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.

The malloc code is glibc is defined with the assumption that brk
clears memory.  Since this is what the kernel implements it would be a
horrible waste of time to reinitialize the memory.  This behavior is
part of the kernel ABI and cannot be changed without breaking existing
applications without producing new libc DSOs (set MORECORE_CLEARS
appropriately) and relinking all statically linked apps.

Re: Zeroed pages returned for heap

[Nagendra Singh Tomar]

On Tue, 7 Jun 2005, Ulrich Drepper wrote:

> On 6/6/05, Nagendra Singh Tomar <nagendra_tomar@adaptec.com> wrote:
> > 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.
> 
> The malloc code is glibc is defined with the assumption that brk
> clears memory.  Since this is what the kernel implements it would be a
> horrible waste of time to reinitialize the memory.  This behavior is
> part of the kernel ABI and cannot be changed without breaking existing
> applications without producing new libc DSOs (set MORECORE_CLEARS
> appropriately) and relinking all statically linked apps.


glibc behaviour is completely justified, but when you are dealing with 
Xscale memory access limitations you wish it was not like that and just 
disabling zeroing brk/anonymous pages in kernel could get you a good bump 
in performance.
Anyway, thanx for the insight.



-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.

Re: Zeroed pages returned for heap

[Peter Staubach]

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.

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?

    Thanx...

       ps

Re: Zeroed pages returned for heap

[Nagendra Singh Tomar]

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


-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.

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.

Re: Zeroed pages returned for heap

[Nagendra Singh Tomar]

On Thu, 9 Jun 2005, Richard B. Johnson wrote:

> On Wed, 8 Jun 2005, Nagendra Singh Tomar wrote:
> 
> 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().

My original question was for glibc (as an application) assuming that 
memory it gets from brk()/MAP_ANON is zero filled, and _not_ for an 
application calling malloc() assuming that. glibc does assume that brk() 
memory is zero filled thats why the glibc calloc() implementation does 
_not_ zero it again in user space (Ulrich conformed this). This is what 
was disturbing to me as I  was trying to disable zero-filling for brk() 
pages and to my unpleasant  surprise few applications like gcc/awk were 
breaking. 

Thanx,
Tomar

-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.