[RFC] ASLR Whitepaper and Candidate Final Patch

[Robert N. M. Watson]

>>>>> Great news that this work is coming to fruition -- ASLR is long overdue.
>>>>> 
>>>>> Are you having any luck with performance measurements?  Unixbench seems like a 
>>>>> good starting point, but I wonder if it would be useful to look, in 
>>>>> particular, at memory-mapping intensive workloads that might be affected as a 
>>>>> result of changes in kernel VM data-structure use, or greater fragmentation of
>>>>> the address space.  I'm not sure I have a specific application here in mind -- 
>>>>> in the past I might have pointed out tools such as ElectricFence that tend to 
>>>>> increase fragmentation themselves.
>>>> 
>>>> The unixbench tests on that laptop have finished. However, I've been
>>>> fighting a pesky migraine these last couple days, so I haven't had the
>>>> opportunity to aggregate the results into a nice little spreadsheet. I'm
>>>> hoping to finish it up by the end of the week.
>>>> 
>>>> I'll take a look at ElectricFence this weekend. Additionally, I have a
>>>> netbook somewhere. Once I find it and its power cord, I'll install
>>>> FreeBSD/x86 and re-run the same tests on that.
>>> 
>>> Somewhat related to ElectricFence? will ASLR have an adverse effect on debuggers?
>>> 
>>> I googled around and got to this:
>>> 
>>> http://www.outflux.net/blog/archives/2010/07/03/gdb-turns-off-aslr/
>> 
>> I've been doing all my ClamAV development on my FreeBSD box with ASLR
>> enabled. Development tools like gdb and valgrind work great, even with
>> corefiles. I have not, however, tried lldb.
> 
> OK, but it’s worth to take a look if we need to support something to turn it off.
> Apparently gdb disables ASLR on MacOSX too:
> 
> http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/
> 
> Pedro.
>