From: Pavel Machek <pavel@ucw.cz>
To: John Richard Moser <nigelenki@comcast.net>
Cc: Arjan van de Ven <arjan@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization
Date: Mon, 22 May 2006 03:06:07 +0200 [thread overview]
Message-ID: <20060522010606.GC25434@elf.ucw.cz> (raw)
In-Reply-To: <446F3483.40208@comcast.net>
On So 20-05-06 11:23:47, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> > On Fri, 2006-05-19 at 21:00 -0400, John Richard Moser wrote:
> >> Any comments on this one?
> >>
> >> I'm trying to control the stack and heap randomization via command-line
> >> parameters.
> >
> > why? this doesn't really sound like something that needs to be tunable
> > to that extend; either it's on or it's off (which is tunable already),
> > the exact amount should just be the right value. While I often disagree
> > with the gnome desktop guys, they have some point when they say that
> > if you can get it right you shouldn't provide a knob.
>
> This is a "One Size Fits All" argument.
>
> Oracle breaks with 256M stack/mmap() randomization, so does Linus' mail
> client. That's why we have 8M stack and 1M mmap().
>
> On the other hand, some things[1][2][3] may give us the undesirable
> situation where-- even on an x86-64 with real NX-bit love-- there's an
> executable stack. The stack randomization in this case can likely be
> weakened by, say, 8 bits by padding your shellcode with 1-byte NOPs
> (there's a zillion of these, like inc %eax) up to 4096 bytes. This
> leaves 1 success case for every 2047 fail cases.
Maybe we can add more bits of randomness when there's enough address
space -- like in x86-64 case?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-05-22 1:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-20 1:00 [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization John Richard Moser
2006-05-20 3:36 ` John Richard Moser
2006-05-20 5:23 ` John Richard Moser
2006-05-20 13:47 ` Arjan van de Ven
2006-05-20 15:23 ` John Richard Moser
2006-05-22 1:06 ` Pavel Machek [this message]
2006-05-22 2:46 ` John Richard Moser
2006-05-22 8:33 ` Pavel Machek
2006-05-22 16:31 ` John Richard Moser
2006-05-22 17:00 ` Pavel Machek
2006-05-22 17:54 ` John Richard Moser
2006-05-22 18:40 ` Pavel Machek
2006-05-22 19:02 ` John Richard Moser
2006-05-22 19:12 ` Pavel Machek
2006-05-22 19:27 ` John Richard Moser
2006-05-22 19:41 ` Pavel Machek
2006-05-22 20:05 ` John Richard Moser
2006-05-23 1:05 ` Arjan van de Ven
2006-05-23 1:34 ` John Richard Moser
2006-05-20 17:13 ` John Richard Moser
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=20060522010606.GC25434@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.