Re: [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization

[Pavel Machek]

Hi!

> > Well, fix emacs then. We definitely do not want 10000 settable knobs
> > that randomly break things. OTOH per-architecture different randomness
> > seems like good idea. And if Oracle breaks, fix it.
> 
> Fix this, fix that.  In due time perhaps.  I'm pretty sure Linus isn't
> going to break anything, esp. since his mail client breaks too.

Good. So fix emacs/oracle/pine, and year or so and some time after it
is fixed, we can change kernel defaults. That's still less bad than
having

[ ] Break emacs

in kernel config.

> Why should it NOT be configurable anyway?  If you don't configure it,
> then it behaves just like it would if it wasn't configurable at all.
> This is called "having sane defaults."

Because if it is configurable, someone _will_ configure it wrong, and
then ask us why it does not work.

And if it is configurable, applications will not get fixed for
basically forever.

> > Per-architecture ammount of randomness would be welcome, I
> > believe. That will force Oracle to fix their code, but that's okay,
> > and you can use disable PF_RANDOMIZE for Oracle in meantime.
> 
> No, this would leave Oracle shipping binaries with PF_RANDOMIZE
> (PT_GNU_STACK still?) disabled.  Also if PF_RANDOMIZE is still connected
> to PT_GNU_STACK, then this means that randomization is turned off BY
> MAKING THE STACK EXECUTABLE.  You should notice the obvious problem
> here.  You should also understand that as long as they can simply switch
> randomization off, they're not going to fix it; and as long as it breaks
> Oracle/Emacs/anything, Linus is not going to impose non-disablable,
> non-adjustable randomization.

I believe that Linus is going to apply this one even less likely.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/