Date: Wed, 30 Jul 2014 22:00:02 -0500 From: Pedro Giffuni <pfg@freebsd.org> To: Shawn Webb <lattera@gmail.com> Cc: PaX Team <pageexec@freemail.hu>, Oliver Pinter <oliver.pntr@gmail.com>, Robert Watson <rwatson@FreeBSD.org>, Bryan Drewery <bdrewery@FreeBSD.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org> In-Reply-To: <20140724175704.GT29618@pwnie.vrt.sourcefire.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Il giorno 24/lug/2014, alle ore 12:57, Shawn Webb <lattera@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: >>>=20 >>>>> - It is yet undetermined what the performance effect will be, and = it is not=20 >>>>> clear (but seems likely from past measurements) if there will be a=20= >>>>> performance hit even when ASLR is off. -Apparently there are = applications=20 >>>>> that will segfault (?). >>>>=20 >>>> 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). >>>>=20 >>>> In each of these three scenarios, I'll have the kernel debugging = features=20 >>>> (WITNESS, INVARIANTS, etc.) turned off to better simulate a = production=20 >>>> system and to remove just one more variable in the tests. >>>>=20 >>>> I'll run unixbench ten times under each scenario and I'll compute = averages. >>>>=20 >>>> Since this is an older laptop (and it's running ZFS), these tests = will take=20 >>>> a couple days. I'll have an answer for you soon. >>>=20 >>> Hi Shawn: >>>=20 >>> Great news that this work is coming to fruition -- ASLR is long = overdue. >>>=20 >>> Are you having any luck with performance measurements? Unixbench = seems like a=20 >>> good starting point, but I wonder if it would be useful to look, in=20= >>> particular, at memory-mapping intensive workloads that might be = affected as a=20 >>> result of changes in kernel VM data-structure use, or greater = fragmentation of=20 >>> the address space. I'm not sure I have a specific application here = in mind --=20 >>> in the past I might have pointed out tools such as ElectricFence = that tend to=20 >>> increase fragmentation themselves. >>=20 >> 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. >>=20 >> 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. >>=20 >>>=20 >>> Also, could you say a little more about the effects that the change = might have=20 >>> on transparent superpage use -- other than suitable alignment of = large=20 >>> mappings, it's not clear to me what effect it might have. >>=20 >> 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. >>=20 >>>=20 >>> I wonder if some equipment in the FreeBSD Netperf cluster might be = used to=20 >>> help with performance characterisation -- in particular, very recent = high-end=20 >>> server hardware, and also, lower-end embedded-style systems that = have markedly=20 >>> different virtual-memory implementations in hardware and software. = Often=20 >>> those two classes of systems see markedly different = performance-change=20 >>> characteristics as a result of greater cache-centrism and = instruction-level=20 >>> parallelism in the higher-end designs that can mask increases in = instruction=20 >>> count. >>=20 >> 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 >>=20 >> 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). >>=20 >>>=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 = with=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 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.=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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?112E989D-607B-47AC-8942-0FB049DA6C3D>