LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jiri Kosina <jkosina@suse.cz>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	kernel list <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Abel Bernabeu <abel.bernabeu@gmail.com>,
	Hugh Dickins <hugh@veritas.com>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [regression] Re: brk randomization breaks columns
Date: Tue, 5 Feb 2008 13:50:51 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802051216340.30955@jikos.suse.cz> (raw)
In-Reply-To: <20080205110632.GB3758@elf.ucw.cz>

On Tue, 5 Feb 2008, Pavel Machek wrote:

> > Actually, this clearly shows that either prehistoric libc.so.5 or the 
> > program itself are broken.
> I believe it shows clear regression in latest 2.6.25 kernel.

I am still not completely sure. It might be a regression, but it also 
might just trigger the bug in ancient version in libc.so.5 which might be 
fixed in some later version -- are you able to verify that?

> You say it is wrong. Manpages imply otherwise:
> 
>        int brk(void *end_data_segment);
> ...
> DESCRIPTION
>        brk()  sets  the  end  of  the  data  segment  to  the  value specified  by
>        end_data_segment, when that value is reasonable, the system does have enough
>        memory and the process does not exceed its max data size (see setrlimit(2)).
> Note it talks about data segment, not about heap, and that seems to
> imply that BSS and heap are actually one area. 2.6.25 broke that.

Single Unix Specification talks only about manipulating the break section, 
see http://opengroup.org/onlinepubs/007908775/xsh/brk.html

> Now, maybe you are right and heap randomization is useful, but breaking 
> 10year old executables is no-no. 

Even if the bug is in 10year old library which might have been fixed by a 
later update? (I don't know how to verify this, libc.so.5 is so ancient 
that it's difficult to find anything about that).

> 1) not enable heap randomization unless app asks for it by personality 
>    syscall

That (beyond other things) doesn't fit into the whole randomization 
picture, as all other aspect of memory space randomization are dependent 
only on 'randomize_va_space' and nothing else ... adding something special 
just for brk seems to be messy.

> 2) (hacky!) detect that app asks for brk() below its heap start, which
> means it assumes BSS+heap are contiguous, and just map the memory there.

That's really ugly :)

> > 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 
> Can you quote docs that tells me it is plain wrong? 

See the Single Unix Specification. It doesn't seem to allow you to assume 
*anything* about start_brk location, seems to me.

Now, I am perfectly fine with reverting that patch for 2.6.25 unless 
someone is able to come up with something clever. It is quite unfortunate 
though, that we possibly give up quite reasonable security measure just 
because 10-year-old libc assumes something that it possibly isn't allowed 
to. Arjan, I know you have been working on brk randomization previously, 
do you have any input here?

Thanks,

-- 
Jiri Kosina
SUSE Labs

  reply	other threads:[~2008-02-05 12:51 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 [this message]
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
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.0802051216340.30955@jikos.suse.cz \
    --to=jkosina@suse.cz \
    --cc=abel.bernabeu@gmail.com \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --subject='Re: [regression] 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).