Any comments on this one?

I'm trying to control the stack and heap randomization via command-line
parameters.  I wrote this in a 2.6.15 Ubuntu Dapper kernel and then
patched it into a 2.6.16.16 tree and cleaned it up.  It does a few
simple things:

 - mmap_random_bits is used to calculate how many pages to shift the
mmap() base around for; I've tested this with 16 bits.
 - stack_random_bits is used to calculate how to shift the stack around.
 If it's >8, then stack_random_bits - 8 is used to shift the page
alignment of the stack.  if it's >0, then its value (or 8 if it's >8) is
used to calculate the interval on which to align the randomly-placed
stack pointer within the first page.  If it's 0, no randomization happens.

I boot tested on Dapper and compared paxtest output.  Here are the
results on a stock Dapper 2.6.15 kernel on i386:

Anonymous mapping randomisation test     : 9 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)

This tells me mmap() randomization is about 10 bits, i.e. randomized
over 4 megabytes.  This is a bit off... the code says it's really 8
bits, 1024*1024 (1MiB) aligned to a 4096 byte page.  It also tells me
the stack is 19 bits, i.e. randomized inside 8MiB, which is correct.

I did a boot with 'mmap_random_bits=16 stack_random_bits=22' with MY
version of the kernel, and got the following results:

Anonymous mapping randomisation test     : 17 bits (guessed)
Shared library randomisation test        : 17 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 22 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 22 bits (guessed)

As shown above, the mmap() randomization test (anonmap, shared libs) is
a bit wonky... the stack test is about right.  In any case, it looks
like it worked.

Just to make sure, I rebooted and tried the test again on my kernel
without passing parameters, with the following results:

Anonymous mapping randomisation test     : 8 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)

So it looks to work.


There's a few other things I want to get done, but I'll worry about
those later.  They are:

 - Take care of the FIXME in that __init code in fs/exec.c to use
architecture-specific #defines for the maximum values of these
parameters, probably in asm-* somewhere.
 - Add /proc controls to tweak system-wide randomization on new processes.
 - Add LSM/SELinux hooks to let policy tweak randomization per-binary,
so high-order randomization can be used except for with i.e. Oracle
(which tries to mmap() 2GiB in at once and can thus die from VMA
fragmentation).
 - Figure out exactly what affects what architecture, and which
architectures react differently in terms of randomization; correct the
calculations in these cases, i.e. if the stack can't be randomized
within the page, stack_random_bits should apply to page randomization.
 - Try getting randomization working in other architectures where it's
not right now.  I don't see anything obvious to me that shows i.e. Sparc
having randomization.. but I'm not much of a kernel hacker....
 - Get somebody to get some sort of heap randomization in here, and do
the same deal.  Doesn't Fedora do heap randomization?



In case anyone is wondering, I did this because when this got in I
complained about it not being anywhere near as good as PaX for entropy;
and I got a lot of replies back about how that kind of randomization
fragments VM *and* *breaks* *stuff*.  This raises two questions:

 - PaX never broke anything I have, so why should I stick with something
weaker?
 - On the other hand, if we move to something with that level of entropy
in mainline, some other people who aren't me break.  How do we deal with
this?

The solution is simple:  I'll use this much entropy, you use that much
entropy, and you can even turn it off if you want to.  That's what this
patch does.  If you want more or need less, turn the knobs up and down.


-- 
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
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension