[RFC] ASLR Whitepaper and Candidate Final Patch

[Tim Kientzle]

On Jul 23, 2014, at 4:37 PM, Pedro Giffuni <pfg at freebsd.org> wrote:

> Hi;
> 
> Il giorno 22/lug/2014, alle ore 19:45, Shawn Webb <lattera at gmail.com> ha scritto:
> 
>>>> ...
>>> 
>>> Hi Shawn:
>>> 
>>> 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/
> 
> So I guess we may have to patch gdb (and lldb)?

I suspect the issue here is that debugging often
requires multiple runs of a program with repeatable
behavior between runs.

Consider:

 * I run the program under GDB, it crashes at a certain PC address

 * I restart the program, set a breakpoint at that PC address

I want to be confident that the PC address where I’m setting the
breakpoint will have the same meaning between runs.

Tim