Date: Thu, 31 Jul 2014 09:30:11 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Pedro Giffuni <pfg@FreeBSD.org> Cc: PaX Team <pageexec@freemail.hu>, freebsd-arch@freebsd.org, Oliver Pinter <oliver.pntr@gmail.com>, Bryan Drewery <bdrewery@FreeBSD.org>, Shawn Webb <lattera@gmail.com> Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <B403DF62-5E21-4212-BA55-F7DF2B1E4331@FreeBSD.org> In-Reply-To: <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <20140724175704.GT29618@pwnie.vrt.sourcefire.com> <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Jul 2014, at 04:00, Pedro Giffuni <pfg@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. >=20 > 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.=20 >=20 > 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=92t 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. >=20 > 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 :(. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B403DF62-5E21-4212-BA55-F7DF2B1E4331>