LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Pavel Machek <pavel@ucw.cz>,
	kernel list <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Abel Bernabeu <abel.bernabeu@gmail.com>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: brk randomization breaks columns
Date: Tue, 5 Feb 2008 13:08:55 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802051243240.542@blonde.site> (raw)
In-Reply-To: <Pine.LNX.4.64.0802050242440.30873@twin.jikos.cz>

On Tue, 5 Feb 2008, Jiri Kosina wrote:
> Now, you are right that the return value from brk() is bogus in these 
> cases. The patch below should make it behave, as you can easily check with 
> strace, right? Does anyone have any comments regarding this patch please?

Your patch below looks good to me, whatever the outcome of the
randomize_brk debate.  I can't imagine what end_code has to do
with it: an ELF binary that specifies the code is to go up the
top of the address space seems perfectly reasonable to me.

> Still, it will probably not fix your particular program crashes, just 
> because it will always assume that brk starts immediately after the end of 
> the bss, which is plain wrong and has never been assured. Could you please 
> check whether there is any compat-* package available for you 
> distribution, that upgrades libc.so.5 to any fixed version?

But I was myself surprised by your randomize_brk patch: like the
buggy program, I'd imagined that data immediately followed by bss
immediately followed by brk was an invariant (whereas I never
supposed the position of the code had anything to do with it).
Just my ignorance, but not surprising if it's shared by others.

So, I didn't really expect the randomize_brk patch to get this far,
thought it would hit trouble earlier.  What to do now?  On the one
hand Pavel rightly regards this as a regression, on the other hand
we've had programs which make bad assumptions about their address
space layout before, and have not always deferred to them.

If such cases are few (can we be sure of that yet?), is it going
to be good enough to rely on adding the ELF note to disable their
randomization?

In my usual dither, I'm rather hoping Arjan will have a clear answer.

Hugh

> From: Jiri Kosina <jkosina@suse.cz>
> 
> brk: check the lower bound properly
> 
> There is a check in sys_brk(), that tries to make sure that we do not 
> underflow the area that is dedicated to brk heap.
> 
> The check is however wrong, as it assumes that brk area starts immediately 
> after the end of the code (+bss), which is wrong for example in 
> environments with randomized brk start. The proper way is to check whether 
> the address is not below the start_brk address.
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Acked-by: Hugh Dickins <hugh@veritas.com>

> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 8295577..1c3b48f 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -241,7 +241,7 @@ asmlinkage unsigned long sys_brk(unsigned long brk)
>  
>  	down_write(&mm->mmap_sem);
>  
> -	if (brk < mm->end_code)
> +	if (brk < mm->start_brk)
>  		goto out;
>  
>  	/*

  parent reply	other threads:[~2008-02-05 13:10 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04 12:28 Pavel Machek
2008-02-04 13:01 ` Ingo Molnar
2008-02-04 13:28   ` Pavel Machek
2008-02-04 14:55     ` Jiri Kosina
2008-02-04 20:25       ` Pavel Machek
2008-02-04 14:33   ` Jiri Kosina
2008-02-04 16:12     ` Jiri Kosina
     [not found]       ` <15577be70802041016m97cddbfk43b9073408bcbce9@mail.gmail.com>
     [not found]         ` <15577be70802041029o2975ba6do34589bbdc81d1652@mail.gmail.com>
2008-02-04 19:52           ` Fwd: " Pavel Machek
2008-02-04 21:54             ` Abel Bernabeu
2008-02-04 22:48               ` Jiri Kosina
2008-02-04 23:13                 ` Abel Bernabeu
2008-02-04 23:39                   ` Pavel Machek
2008-02-04 20:31       ` Pavel Machek
2008-02-05  1:57 ` Jiri Kosina
2008-02-05 11:06   ` [regression] " Pavel Machek
2008-02-05 12:50     ` Jiri Kosina
2008-02-05 12:54       ` Ingo Molnar
2008-02-05 13:05         ` Jakub Jelinek
2008-02-05 16:18           ` Pavel Machek
2008-02-05 16:37             ` Ingo Molnar
2008-02-05 16:12       ` Pavel Machek
2008-02-05 13:08   ` Hugh Dickins [this message]
2008-02-05 15:00     ` Arjan van de Ven
2008-02-05 15:46       ` Pavel Machek
2008-02-05 15:49         ` Jiri Kosina
2008-02-05 15:55           ` Pavel Machek
2008-02-05 15:49         ` Ingo Molnar
2008-02-05 15:59           ` Pavel Machek
2008-02-05 16:06             ` Ingo Molnar
2008-02-05 22:03               ` Pavel Machek
2008-02-05 16:58         ` Arjan van de Ven
2008-02-05 17:33           ` Pavel Machek
2008-02-05 22:35           ` Jiri Kosina
2008-02-06  3:24             ` Randy Dunlap
2008-02-05 16:02   ` Pavel Machek
2008-02-05 16:09     ` Ingo Molnar
2008-02-05 22:04       ` Pavel Machek
2008-02-05 18:05   ` Pavel Machek
2008-02-05 20:42     ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0802051243240.542@blonde.site \
    --to=hugh@veritas.com \
    --cc=abel.bernabeu@gmail.com \
    --cc=arjan@infradead.org \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --subject='Re: brk randomization breaks columns' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).