[RFC] ASLR Whitepaper and Candidate Final Patch

[Robert N. M. Watson]

On 31 Jul 2014, at 04:00, Pedro Giffuni <pfg at FreeBSD.org> wrote:

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

I'm not sure that the three numbers presented are meaningful at all: we can't tell if the differences are significant or not, because we don't have a sense of the distributions from which the numbers fall. If the difference between 'no patch' and 'disabled' is in fact negligible as one would expect given the contents of the patch, then it suggests the variance in the tool's output number is quite high -- calling into question any interpretation of the difference between 'disabled' and 'enabled'. Selecting some suitable benchmarks and doing a proper analysis is definitely required.

The other more abstract point here is not the immediate performance consequences, but also the effect they have on future possible optimisations. In the past, we (and many others) have toyed with prelinking techniques, in which run-time linking costs are amortised by preestablishing virtual-address bindings for frequently used libraries. That optimisation is basically entirely antithetical to ASLR, which is premised on doing precisely the opposite. I don't take a strong view on the value of prelinking, although will observe that it is a technique that pops in and out of fashion pretty frequently; it's currently 'out' but presumably will be back 'in' again in the future. With prelinking, there is presumably a sharp cliff associated with ASLR being enabled.

I would quite like to understand where the modest 'expected' performance drop in ASLR is supposed to come from; as the PaX folk have suggested, a decent implementation might have little or no overhead if we think it doesn't seriously disturb VM/TLB use on 64-bit platforms -- there's not very much cost to pulling a bit of entropy from Yarrow/Fortuna if it is suitably amortised, and unlike on Linux, you won't block waiting on it due to Yarrow/Fortuna sitting between the consumer and the entropy pool. On 32-bit systems you'd expect ASLR to be both pretty ineffective in terms of bits of entropy available, and catastrophic for address-space fragmentation, but on 64-bit systems much more reasonable. Does anyone have any thoughts on this?

Robert