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

From: John Richard Moser
Date: Mon May 22 2006 - 12:36:02 EST

Hash: SHA1

Pavel Machek wrote:
> Hi!
>>>>> 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?
>> Yes but how many? I set the max in my working copy (by the way, I
>> patched it into Ubuntu Dapper kernel, built, tested, it works) at 1/12
>> of TASK_SIZE; on x86-64, that's 128TiB / 12 -> 10.667TiB -> long_log2()
>> - -> 43 bits -> 8TiB of VMA, which becomes 31 bits mmap() and 39 bits stack.
>> That's feasible, it's nice, it's fregging huge. Can we justify it? ...
>> well we can't justify NOT doing it without the ad hominem "We Don't Need
>> That Because It's Not Necessary", but that's not the hard part around here.
> Well, making it configurable and pushing hard decision to the user is
> not right approach, either. I believe we need different
> per-architecture defaults, not "make user configure it".

Yes, different per-architecture defaults is feasible with configuration
being possible. I could replace 'int STACK_random_bits=19' with 'int
mmap_random_bits=ARCH_STACK_RANDOM_BITS_DEFAULT' and that would be
effective as long as the user doesn't touch it with command line or
SELinux or whatnot.

It is still possible that ARCH_STACK_RANDOM_BITS_DEFAULT breaks things.
The current kernel default broke emacs at first I heard; I believe we
started with 64KiB of stack randomization and then upped it to 8MiB when
emacs was fixed. In this case we have 3 options:

- Disable PF_RANDOMIZE for the binary. (Already doable)
- Decrease randomization system-wide. (My patch lets you do this)
- Decrease randomization for the binary to a point where it works.
(Adding SELinux hooks and policy to my patch would allow this)

Obviously decreasing randomization system-wide has other implications:
your entire system is as weak as the weakest link, even if that weakest
link is a privilege-restricted non-networked text editor. Another
consideration is that Oracle breaks with high-order entropy; but Apache
is quickly brute-forceable even with high-order entropy (216 seconds an
average according to a paper about brute forcing PaX ASLR on i386). We
increase the risk here to fit the need there... not good.

Disabling randomization for the binary is much more fine-grained, but
opens up that binary for attacks. Oracle breaks with high-order
entropy; we can disable randomization on Oracle and keep high-order
entropy, but now the database server is at risk. This isn't the
greatest idea in the world either.

Decreasing randomization as per policy on specific binaries is a
security win. Apache is much safer with high-entropy ASLR; Oracle
breaks from it but lives with low-entropy ASLR and that's better than
nothing; most of the rest of the system doesn't really care and some
benefits some doesn't. The only problem is somebody has to configure
that, putting load on the administrator.

It appears to me that the best solution is per-policy, but we should
leave even that up to the user. This means make a sane default-- one
that shouldn't break anything, but supplies some kind of benefit-- and
only stray from that at the user's request. This is why I wrote a
command line patch and am interested in SELinux policy controls for
randomization entropy.

> Pavel

- --
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
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

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