From owner-freebsd-arch@FreeBSD.ORG Thu Jul 31 03:00:14 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 D0C815F2 for ; Thu, 31 Jul 2014 03:00:14 +0000 (UTC) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CF1A27CA for ; Thu, 31 Jul 2014 03:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1406775607; bh=nK+8ewItBakKIkJSYsuxVZ/ewRmX8ScjxUFvCNFdaAc=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=dUN5UOU0DeFGjYf0PX4dnpDB7Dlsx1dlpgo0p4rA2RqUBtgEyynL6ZBA03d6LcitJcXfM0+Uo91fbbXENf1tZ7W/mo6Wb+X4FW7P4nKEflGr5tCt9n4XuMh2EHnp3fAp6h/0zkMXTTVBrSfBWFu4jdXc0uhoRDoRboNixNVA9WFelsaSzdg3NYPj32FXwnVbcznASOq+nNjGix1/vYOwsanhf7Otl3YwYe6aLReSxIIL5xjec3Qznbc92aepdZ+yuBVedFDyRv2Ka0ygIdXMnxDAmGrm8K30NuSvAq6VWKaraZih8g+NQeY4G8Rslq45G0NPQfS/DdnHXkhmLQ2rTA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=qnVJ0DZVtojq7tIUd4O7vf3okCg302ohgc7/TGxMSSfmFxis5vy//aHKrnqpjR7FYHqUFiLVNfp/mbUY4b464bolTtXegHqDIpNP4BSVHaZ0Vid+60AHfrsqqF0P34XJNGryhSl1HegMC1iJDhgFND19Is0uaUDyd4CL2G0IvvlQQini7KgUPmh9V5BCMOp1y3RhwNvNVhyw76FmVRyrp39tc4b1rvjO1Cq4jEHBANqB0zJJhT59cMZ0Y7gBtzfY5SCfexkEprmH4plZ3S5Qkiq5Sy6HZxZ99aBFzp9+sxs283P85uI1rkmoPGZDr4JezfZ5qFeJZlhF8eJDP8EeCw==; Received: from [66.196.81.173] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 03:00:07 -0000 Received: from [98.139.211.163] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 03:00:07 -0000 Received: from [127.0.0.1] by smtp220.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 03:00:07 -0000 X-Yahoo-Newman-Id: 761958.64427.bm@smtp220.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZLjC2LUVM1mCfnrKg_ChLBKfWJJrp0.4EFE5TLKVFHxeRmi 3JvWSL4fQujsZciSzqNIqBxYFoQywHY_Lvh6iwdSI5vo9dM8q2ifdWxMlEXy byndjEpyLoreAdXY5.vaU5bBk3OjicpD0YcYcPxr53EKGUTySHQNvr1Qq96Y L3IrAsTXkJgWdG3MDNKtbV8mXQeS_MJjSL38RT3o5_yprLTvLcNgvLch66qO YSLwRj.xHocH_fFSMBWe8cJoIPxrIPMqATXyKw9PWrPgYn3MRaLLHWB4kUo6 QU3.8g9NvSpKBVqHTyLOcXiMV6.7OYrOTc7My4MJxmaeV.gGpI0RWq8aV6vD j3ULMvDYRobMUGuavoY.eca9lOyyaVvKPXdDG2Nk02ewrRcwfDUlNk502Szg _kARwffpe7fv3GCIXqT.5pik3My3uj1QYgrv8lgNbMKe0pLo3LS.vGbpItgs HyREF10ucbSgSlOk12Mnt72XwuFRmAe1yiFns3pE9SG0Kpt5DSPjNNKw90qV yqRngVCMyK_AeUHfu.adCHOWqBn8JNoxPXlJhvBv8YE8QjgAEAFiL4JBUgSM z9PQvyN.1ct9XWmee2Fkqb8LXfg9FRRulGz1E8RNL_LQfI20._Zm0xpk1DHP toIE4W_YgbAAAZKobImWwevIUAzKMBCgFwmA2hAvrG7nmkMJYf0NveeziPbg W1XrSrmG9QGcDWHib.4LhpLqDm6sgqIsxEiVVj61alGuFvVeANw-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch From: Pedro Giffuni In-Reply-To: <20140724175704.GT29618@pwnie.vrt.sourcefire.com> Date: Wed, 30 Jul 2014 22:00:02 -0500 Message-Id: <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org> 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> To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: PaX Team , Oliver Pinter , Robert Watson , Bryan Drewery , freebsd-arch@freebsd.org 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 03:00:14 -0000 Il giorno 24/lug/2014, alle ore 12:57, Shawn Webb 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.