Re: Zeroed pages returned for heap

From: Richard B. Johnson (linux-os_at_analogic.com)
Date: 06/09/05

  • Next message: Jan-Benedict Glaw: "IPv6 related BUG (./net/ipv6/exthdrs_core.c:ipv6_skip_exthdr())" 
    Date:	Thu, 9 Jun 2005 06:14:05 -0400 (EDT)
To: Nagendra Singh Tomar <nagendra_tomar@adaptec.com>

    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,
    *** 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jan-Benedict Glaw: "IPv6 related BUG (./net/ipv6/exthdrs_core.c:ipv6_skip_exthdr())"