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

From: Pavel Machek
Date: Mon May 22 2006 - 15:12:32 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
> > having
> >
> > [ ] Break emacs
> >
> > in kernel config.
> Nobody is going to fix emacs/oracle/pine, they don't have to. Nothing
> is making them. The kernel will wait for them so who cares.

No, _you_ have to fix emacs/oracle/pine. You claimed your patch is
interesting for secure distros, so you obviously have manpower for
that, right?

> >> 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.
> Oh big deal. People configure out ide drivers and ask why their kernel
> doesn't boot all the time. Distro maintainers do most of the work.

As you may have noticed, I'm at receiving end of those bug
reports. And what you propose is actually *worse* than IDE, because at
least you get relatively clear error message when misconfiguring IDE.

> > And if it is configurable, applications will not get fixed for
> > basically forever.
> FUD. If it's not configurable, applications will not get fixed for
> basically forever, and nobody will put the breaking code into mainline.
> Linus is NOT giving 256M/256M randomization on mainline as default
> ever.

For x86-64... why not?

(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