Date: Fri, 25 Jul 2014 18:37:53 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: Shawn Webb <lattera@gmail.com>, Oliver Pinter <oliver.pntr@gmail.com>, Pedro Giffuni <pfg@freebsd.org>, freebsd-arch@freebsd.org, PaX Team <pageexec@freemail.hu>, Bryan Drewery <bdrewery@FreeBSD.org> Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <20140725153753.GB93733@kib.kiev.ua> In-Reply-To: <F0959F48-53D2-4F9B-9FC2-641F8BD6A5EC@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> <F0959F48-53D2-4F9B-9FC2-641F8BD6A5EC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZZtaxrRwL/ezAVYu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 25, 2014 at 08:17:36AM +0100, Robert N. M. Watson wrote: >=20 > On 24 Jul 2014, at 18:57, Shawn Webb <lattera@gmail.com> wrote: >=20 > >>> I think someone has already commented that Peter Holm's help might be= =20 > >>> enlisted; you have have seen his 'stress2' suite, which could help wi= th=20 > >>> stability testing. > >>=20 > >> I'll take a look at that, too. Thanks a lot for your suggestions and > >> feedback. > >=20 > > The unixbench results are in. The overall scores are below. > >=20 > > ASLR Disabled: 456.33 > > ASLR Enabled: 357.05 > > No ASLR: 474.03 > >=20 > > I've uploaded the raw results to > > http://0xfeedface.org/~shawn/aslr/2014-07-24_benchmark.tar.gz > >=20 > > 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. >=20 > Just in case you've not spotted it, there's some useful benchmarking > advice here: > > https://wiki.freebsd.org/BenchmarkAdvice > > Unfortunately, the numbers above are a bit opaque, as it's not clear > whether the differences/non-differences are statistically significant. > Likewise, we'd expect that ASLR might impact some types of behaviour > more than others, and so reduction to a single number can overlook > problems or overemphasise differences. For now, the key thing is > really that there not be any measurable performance difference when > ASLR is disabled, and the numbers above make it a bit unclear if > that is the case. The numbers are definitely difference above -- but > perhaps this is a result of non-essential code generation differences, > noise in the run, etc. Typically, you would want to use a technique > such as a t-test to compare runs and decide if the difference is > significant. Tools such as ministat are very useful here, although you > have to be a bit careful as most performance measurements are already > arithmetic means due to the need to run individual instances of the > operation of interest many times, and comp aring means of means is a > messy business. > > The next direction will be to dig more into areas where there are > statistically significant changes to decide whether they are caused > by ASLR, or perhaps are just non-essential differences in code > generation. It may be useful to consider using a suite like 'libmicro' > that can drill into individual system-call behaviour more, as well as > larger-scale benchmarks that consider the behaviour of applications > with realisticish workloads -- Postgres has been of particular > interest lately. The unixbench includes the execve(2) speed test, AFAIR. It is probably the only relevant test from the whole suite. Benchmarking the proposed bug is hard, because it affects mostly the loads which are typically excluded from the normal benchmark's measurement phases. The setup stage, where the image is activated and faulting of the pages needed for the later steady stages is the most vulnerable. The benchmarks itself would typically execute in the mode where only larger page tables, and correlated higher TLB miss frequency could be observed. I expect that the later is hidden by L2 cache if the test working set fits into L2. --ZZtaxrRwL/ezAVYu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0nnQAAoJEJDCuSvBvK1Bh5sP/0ntjqKcSWQP3j3PteT7LHdB BW8y032uIi6FDJywDS4uG8k8lCm7OC/J4uFEnA7z5DMEicLUO02jOhy5cmUH4+a0 m4HkkVjvKZW2FRVcEggrf/cD+doSC2SZ2GqYaKCrYEq4WCuZe18z+TcMH0u8WosD hamBMcECXaYlkTG3sesW2kZd7tYVhj35c77avzw8m9cl33f5Iuo6maUSGIOBFcR+ r40ubtE5fuBshlA+emnTlaNE0qWsxZSK7dlP2LHtrXActI9hAGY0ZeAcO5tHhusr dHp0vc4oaw6f2awaLcU7yul0RfFVMrpZxkXEyOxi3UVn/lMzN2+MUZmI2PjHzkP8 6hA4yNKCyGWKg+zBTcoCERq14Os6lKkViR+0PPeybVanoPxGyYW0UGWPNPNSRhEI LdS+YYH55zXxPrePShhIk4m0hZf2Gzj5AxQU7zIoB20tnrLbtSF2RmrA4pURf4l4 Zrm9yV1+du3mv/Eogd98FUH273bIprZSGhMK0zna3M3cIIdzWShBI7cKWpztBHfD 2JR+5R1BUqDdflhCQOQCFLSAVCgvzTdS7IPkR7AhVH2djfxJYXCImetb+ahXboJu lgBRF4ryPu+m7qoSnymNRdpsT6APi6xjCEbB9ihb/e/iAEjGJzjBZ5JDHalGAbFF LDDihhNu3JWAl3YSM8PV =Llzq -----END PGP SIGNATURE----- --ZZtaxrRwL/ezAVYu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140725153753.GB93733>