From owner-freebsd-arch@FreeBSD.ORG Thu Jul 31 08:30:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 253A77AA; Thu, 31 Jul 2014 08:30:18 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id D43482993; Thu, 31 Jul 2014 08:30:17 +0000 (UTC) Received: from [10.0.1.9] (host86-132-108-36.range86-132.btcentralplus.com [86.132.108.36]) by cyrus.watson.org (Postfix) with ESMTPSA id 7D6D246B2C; Thu, 31 Jul 2014 04:30:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch From: "Robert N. M. Watson" In-Reply-To: <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org> Date: Thu, 31 Jul 2014 09:30:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> <20140724175704.GT29618@pwnie.vrt.sourcefire.com> <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.1878.6) Cc: PaX Team , freebsd-arch@freebsd.org, Oliver Pinter , Bryan Drewery , Shawn Webb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 08:30:18 -0000 On 31 Jul 2014, at 04:00, Pedro Giffuni 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