Re: [PATCH] 188.8.131.52 Parameter-controlled mmap/stack randomization
From: John Richard Moser
Date: Mon May 22 2006 - 15:31:56 EST
-----BEGIN PGP SIGNED MESSAGE-----
Pavel Machek wrote:
>>>>> 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.
>> 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?
RHAT probably fixed Emacs already since it broke on them. Adamantix and
Hardened Gentoo are most likely to put manpower into things like pine..
they put a lot of work into removing textrels on i386.
Oracle we can't do anything about. It's commercial. If we break it,
they will recommend running it on Solaris or Windows 2003.
>>>> 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.
Yes but when you misconfigure IDE the system doesn't boot. When you
turn up randomization too high, everything works but 1 or 2 programs.
You bitch to your distro or to the upstream programmer and they tell you
"It won't function like that, do this" or "We don't know right now" and
you make the connection and turn it back down or wind up here.
If you get that far, at least you know what you did and how to undo it.
>>> 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
> For x86-64... why not?
On x86-64 he may, if you can convince him it's useful (asserting that
turning entropy up on i386 is non-useful is not a good start hinthint).
On i386 or other 32-bit where TASK_SIZE is a few GiB, no chance in
hell, but it'd be nice to be able to tweak it upwards if desired.
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
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/