[RFC] ASLR Whitepaper and Candidate Final Patch

Thu Jul 31 03:00:14 UTC 2014

Il giorno 24/lug/2014, alle ore 12:57, Shawn Webb <lattera at gmail.com> ha scritto:

> On Jul 22, 2014 08:45 PM -0400, Shawn Webb wrote:
>> On Jul 23, 2014 12:28 AM +0100, Robert Watson wrote:
>>> On Sun, 20 Jul 2014, Shawn Webb wrote:
>>> 
>>>>> - It is yet undetermined what the performance effect will be, and it is not 
>>>>> clear (but seems likely from past measurements) if there will be a 
>>>>> performance hit even when ASLR is off. -Apparently there are applications 
>>>>> that will segfault (?).
>>>> 
>>>> So I have an old Dell Latitude E6500 that I bought at Defcon a year or
>>>> so ago that I'm doing testing on. Even though it's quite an underpowered
>>>> laptop, I'm running ZFS on it for BE support (in case one of our changes
>>>> kills it). I'll run unixbench on it a few times to benchmark the ASLR
>>>> patch. I'll test these three scenarios:
>>>>   1) ASLR compiled in and enabled;
>>>>   2) ASLR compiled in and disabled;
>>>>   3) ASLR compiled out (GENERIC kernel).
>>>> 
>>>> In each of these three scenarios, I'll have the kernel debugging features 
>>>> (WITNESS, INVARIANTS, etc.) turned off to better simulate a production 
>>>> system and to remove just one more variable in the tests.
>>>> 
>>>> I'll run unixbench ten times under each scenario and I'll compute averages.
>>>> 
>>>> Since this is an older laptop (and it's running ZFS), these tests will take 
>>>> a couple days. I'll have an answer for you soon.
>>> 
>>> 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.
>> 
>>> 
>>> Also, could you say a little more about the effects that the change might have 
>>> on transparent superpage use -- other than suitable alignment of large 
>>> mappings, it's not clear to me what effect it might have.
>> 
>> Since we're just modifying the hint passed to the underlying VM system,
>> superpage support works as it should with ASLR enabled. The VM system
>> will modify the hint in order to be able to use superpages. In those
>> cases, we might lose a little bit of entropy. However, due to superpages
>> (on amd64, at least) requring 2MB alignment, you'd lose some entropy no
>> matter how ASLR was implemented--at the end of the day, you need that
>> alignment for superpages to work.
>> 
>>> 
>>> I wonder if some equipment in the FreeBSD Netperf cluster might be used to 
>>> help with performance characterisation -- in particular, very recent high-end 
>>> server hardware, and also, lower-end embedded-style systems that have markedly 
>>> different virtual-memory implementations in hardware and software.  Often 
>>> those two classes of systems see markedly different performance-change 
>>> characteristics as a result of greater cache-centrism and instruction-level 
>>> parallelism in the higher-end designs that can mask increases in instruction 
>>> count.
>> 
>> Any additional testing would be very much welcome. Our ASLR
>> implementation misbehaves on ARM, so testing on ARM-based embedded
>> devices is pretty limited. My next goal is to figure out why it bugs out
>> on ARM. Essentially, when a child process exits/dies and the parent
>> process gets sent SIGCHLD, the parent process' pc register somehow gets
>> set to 0xc0000000 and segfaults. Here's a screenshot of the process:
>> https://twitter.com/lattera/status/490529645997998080
>> 
>> FreeBSD 11-CURRENT hasn't been stable at all on sparc64, even without
>> the ASLR patches. I have an SunFire 280R box that I've attempted to test
>> ASLR our on, but I couldn't get a stable enough installation of vanilla
>> FreeBSD to work long enough to recompile world/kernel. And generating an
>> installation ISO from my amd64 box doesn't work as the VTOC8 bootloader
>> isn't recognized by the BIOS (not sure if that's what it's called in
>> sparc land).
>> 
>>> 
>>> I think someone has already commented that Peter Holm's help might be 
>>> enlisted; you have have seen his 'stress2' suite, which could help with 
>>> stability testing.
>> 
>> I'll take a look at that, too. Thanks a lot for your suggestions and
>> feedback.
> 
> The unixbench results are in. The overall scores are below.
> 
> ASLR Disabled: 456.33
> ASLR Enabled:  357.05
> No ASLR:       474.03
> 
> I've uploaded the raw results to
> http://0xfeedface.org/~shawn/aslr/2014-07-24_benchmark.tar.gz
> 
> Take these results with a grain of salt, given that some of unixbench's
> test are filesystem-related and I'm running ZFS on an old laptop with
> little RAM. It does show that there is a performance impact when ASLR is
> enabled.
> 

The effect of the available RAM and/or age of the system is
independent of ASLR being on or off si I think the results are valid.

As Robert said, the particularly bad result is the effect of having ASLR
disabled vs not having the patch at all. The priority should certainly be
to fix this. 

The effect of ASLR seems significant, I did expect it less but it is something
that can be expected. People that enable ASLR have to be aware that there
are consequences performance-wise. A further effect that hasn’t been quantified
but could be obtained from the raw data is the standard deviation. I would expect
that the randomization induced from using ASLR will cause an important increase
in the standard deviation and that performance will be basically unpredictable.

The last issue is a show stopper from enabling ASLR by default but the first
issue is a show stopper from committing the patch at all :(.

Of course, all just IMHO.

Pedro.