Date: Wed, 29 Sep 2004 16:11:51 +0200
From: Andrea Arcangeli <andrea@novell.com>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: heap-stack-gap for 2.6
Message-ID: <20040929141151.GJ4084@dualathlon.random>
References: <20040925162252.GN3309@dualathlon.random> <1096272553.6572.3.camel@laptop.fenrus.com> <20040927130919.GE28865@dualathlon.random> <20040928194351.GC5037@devserv.devel.redhat.com> <20040928221933.GG4084@dualathlon.random> <20040929060521.GA6975@devserv.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040929060521.GA6975@devserv.devel.redhat.com>
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2785
Lines: 68

On Wed, Sep 29, 2004 at 08:05:21AM +0200, Arjan van de Ven wrote:
> oh? you mean that 1Mb gap between stack and topdown? Every ISV I talked to
> said they could get more VA space with topdown than with the suse
> mmaped_base hack... :)

/*
 * Top of mmap area (just below the process stack).
 *
 * Leave an at least ~128 MB hole.
 */
#define MIN_GAP (128*1024*1024)
#define MAX_GAP (TASK_SIZE/6*5)

where does your 1M comes from? it's a minimum 128Mbytes.

> MAP_FIXED is to be used only on things YOU mmaped before. 

where is that written?

> > isn't the whole point of topdown to gain ~1G more of RAM. A 1G area that
> > couldn't possibly be used before
> 
> wrong; brk() is there which is also used by malloc() and internally by the C
> library.

that's malloc, but mmaps don't fit into it.

So sure, apps where careful about malloc, but not about mmap. mmap was
guaranteed not to mess in the area below 1G, now it does and can break
stuff.

> do you have proof for that?

do I need to write the exploited testcase? just let me know, it'll take
only a few minutes.

as usual, since the screwup generated by topdown would be random and at
runtime, one cannot exclude it could generate a security compromise.

Amittedly it sounds very unlikely that can break stuff, but it can.

> You missed that you can only use MAP_FIXED on mmaps YOU mmaped before.
> That's true for basically all operating systems because the runtime
> (including C library) is allowed to malloc, to brk(), to mmap etc etc.

small malloc works below the 1G area, but it's the application that has
to use malloc. I'm talking about an application that uses heavy mmap,
MAP_FIXED below 1G and _never_ mallocs. It's up to you to call malloc,
if you didn't, you had the guarantee that you could use the space near
1G. The mapped_base is the safe API to tell the kernel it can use the
memory below 1G for the heap.

now the best thing is the ADDR_COMPAT_LAYOUT personality, that is what
can make it safe, and I hope it's enabled by default on all apps, but
I'm afraid it's the other way around, i.e. that the application will be
marked "compatible" after it breaks at runtime. Plus the testing will be
decreased since most people runs with unlimited stack (which defaults to
bottomup beahviour).

the single fact you added ADDR_COMPAT_LAYOUT means you're very well
aware there are apps that will break, or there would be no point for a
"COMPAT" option, if it was really backwards compatible by default, or do
I misunderstand the semantics of ADDR_COMPAT_LAYOUT personality?
-
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/