Re: [RFC PATCH 1/1] MIPS: Enable VDSO randomization.

[David Daney <ddaney.cavm@gmail.com>]

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.
>
>