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

> 
> 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.

the surprise also will be when gcc reorders your .data section for optimization,
and the variable you think is last.. no longer isn't.

> 
> 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

it's for sure only few; this is the second known case is 5 years
that made this dicey assumption (RHEL/Fedora ship with this for 5 years or so now)
Various "secure" distros ship with brk detached as well (albeit via other methods)
for even longer.

> to be good enough to rely on adding the ELF note to disable their
> randomization?

sadly elfnotes are a sparse commodity.
> 
> In my usual dither, I'm rather hoping Arjan will have a clear answer.


setarch works. If the apps come in source form they need fixing anyway (since I'd not be
surprised of current gcc reorders variables), if not.. we only have 2 cases,
the other case was the build process of emacs (which got fixed 5 years ago).
My personal guess is, if there's nothing more than "columns", lets swallow it.
If more show up, we need to rethink it. I somehow doubt more real apps will show
up given how widespread and long this patch was deployed... but turning of randomization
already exists via various methods, both global and per process.

  reply	other threads:[~2008-02-05 15:00 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
2008-02-05 15:00     ` Arjan van de Ven [this message]
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=20080205070001.7bc8058f@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=abel.bernabeu@gmail.com \
    --cc=hugh@veritas.com \
    --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).