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

From: Pavel Machek
Date: Mon May 22 2006 - 14:40:06 EST


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

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

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at