On 04/20/2014 08:40 PM, Prem Karat wrote:
On 04/19/14 03:56pm, David Daney wrote:
On 04/19/2014 02:33 AM, Prem Karat wrote:
Based on commit 1091458d09e1a (mmap randomization)
For 32-bit address spaces randomize within a
16MB space, for 64-bit within a 256MB space.
How was it tested (i.e. what workload did you run to verify that the
kernel still functions with this change)?
David, Sergei,
Thank You for reviewing the patch.
Am using test suite from Ubuntu which is available here.
http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/scripts/kernel-security/aslr/
As you probably know, currently the "vdso" in mips is really only used
for signal return trampolines. So to properly test it, you need code
that does returns from signal handlers.
Does your test suite do that?
Please find the test results below.
Without Patch (VDSO is not randomized)
---------------------------------------
root@Maleo:~# ./aslr vdso
FAIL: ASLR not functional (vdso always at 0x7fff7000)
root@Maleo:~# ./aslr rekey vdso
pre_val==cur_val
value=0x7fff7000
[...]
+
+ return (STACK_TOP + offset);
How can you be sure this address doesn't collide with, or otherwise
interfere with, the stack?
It doesn't, as this program can print the maps file and here is the output of the
maps file each time we run aslr showing maps file.
root@cavium-octeon2:~# ./aslr rekey maps
78584000-785a5000 rwxp 00000000 00:00 0 [heap]
7f9d0000-7f9f1000 rw-p 00000000 00:00 0 [stack]
7ffa5000-7ffa6000 r-xp 00000000 00:00 0 [vdso]
root@cavium-octeon2:~# ./aslr rekey maps
77de0000-77e01000 rwxp 00000000 00:00 0 [heap]
7f91b000-7f93c000 rw-p 00000000 00:00 0 [stack]
7ff99000-7ff9a000 r-xp 00000000 00:00 0 [vdso]
root@cavium-octeon2:~# ./aslr rekey maps
77d7f000-77da0000 rwxp 00000000 00:00 0 [heap]
7fc2a000-7fc4b000 rw-p 00000000 00:00 0 [stack]
7fe09000-7fe0a000 r-xp 00000000 00:00 0 [vdso]
root@cavium-octeon2:~# ./aslr rekey maps
7794c000-7794d000 r-xp 00000000 00:00 0 [vdso]
77e4b000-77e6c000 rwxp 00000000 00:00 0 [heap]
7f6e7000-7f708000 rw-p 00000000 00:00 0 [stack]
root@cavium-octeon2:~#
Four test runs is not enough to satisfy my curiosity. It could be that
in these test cases, the random numbers never lined up for a collision.
You are attempting to generate two random memory maps (Stack and VDSO)
that are in the same region of memory. How does the system handle the
possibility that the initial random values would collide for these two
things.
Showing a few runs of a test program is not enough. I would like an
explanation of what happens when there is a collision, and how the
system properly handles it.
Thanks,
David Daney
Also, as mentioned by Sergei, run checkpatch.pl to catch obvious
stylistic problems before submitting patches.
I will make the changes and send a v2 patch.
