From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 21:47:12 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 68F15EE2; Wed, 23 Jul 2014 21:47:12 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E02C12E05; Wed, 23 Jul 2014 21:47:11 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id f51so2207364qge.4 for ; Wed, 23 Jul 2014 14:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=jH0Y1nxmk7HSnJXrKKhKv9OOXAGqOUSnJINt5KfbAbw=; b=TSF6U+Q2K6Qst3MU2eoeAYUijk3KarPjm+ceXUr2ilayM+6iYIHhiigvx5z6ThlJyf YplseFNMjPS4PRCpo6GHxuWCZX+uJQYD1eI/KpnBY4U618TAr1CtRskp2a1/Z/EX1hJk MV5ztQNm2edfNTyKKqHnw5NIgY1NQ23h0g3BjObcgQ7O50BxpjESZrmHaGyGa2TVDc1c WZ6aMB4cWOPuNMWQPFmrTwXZxoAmIiuen9usDQmBsoX1qM4liOSjZV6YJIdFzGLOs3fF o9Fy3mgSEKcjzfC6Cw7mHCQoJswa2ZwNHb1z864pVC5P7CMtlHqaHzD+RucU/i3jrxVo Qfdw== X-Received: by 10.140.21.137 with SMTP id 9mr6605327qgl.37.1406152030952; Wed, 23 Jul 2014 14:47:10 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id z11sm5919773qaz.45.2014.07.23.14.47.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jul 2014 14:47:10 -0700 (PDT) Date: Wed, 23 Jul 2014 17:47:08 -0400 From: Shawn Webb To: Robert Watson Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <20140723214708.GO29618@pwnie.vrt.sourcefire.com> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <20140723004543.GH29618@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KM+e2hnYAO+MCJ5e" Content-Disposition: inline In-Reply-To: <20140723004543.GH29618@pwnie.vrt.sourcefire.com> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: PaX Team , Pedro Giffuni , Oliver Pinter , 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: Wed, 23 Jul 2014 21:47:12 -0000 --KM+e2hnYAO+MCJ5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 applica= tions=20 > > >> that will segfault (?). > > > > > > 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 underpowe= red > > > laptop, I'm running ZFS on it for BE support (in case one of our chan= ges > > > 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). > > > > > > In each of these three scenarios, I'll have the kernel debugging feat= ures=20 > > > (WITNESS, INVARIANTS, etc.) turned off to better simulate a productio= n=20 > > > system and to remove just one more variable in the tests. > > > > > > I'll run unixbench ten times under each scenario and I'll compute ave= rages. > > > > > > Since this is an older laptop (and it's running ZFS), these tests wil= l 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 affecte= d as a=20 > > result of changes in kernel VM data-structure use, or greater fragmenta= tion 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 t= end 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 mig= ht 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 hi= gh-end=20 > > server hardware, and also, lower-end embedded-style systems that have m= arkedly=20 > > different virtual-memory implementations in hardware and software. Oft= en=20 > > those two classes of systems see markedly different performance-change= =20 > > characteristics as a result of greater cache-centrism and instruction-l= evel=20 > > parallelism in the higher-end designs that can mask increases in instru= ction=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 > Thanks, >=20 > Shawn Update: I've uploaded the patch for review to phabricator: https://phabric.freebsd.org/D473 The uploaded patch does NOT contain the mac_bsdextended(4)/ugidfw(8) integration. With that said, though, one change to one of the mac_bsdextended(4) headers has been left in this patch as it is the main integration point for per-binary ASLR toggles. If we decide not to use mac_bsdextended(4)/ugidfw(8) at all, that change can be moved to the main sys/pax.h header rather than the mac_bsdextended(4) header. I'm going to work later this evening on aggregating and preparing the benchmark results. Hopefully I'll have the results ready for you all tomorrow. Thanks, Shawn --KM+e2hnYAO+MCJ5e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0C1bAAoJEGqEZY9SRW7uXEwP/3QNaq1S54Rp3oXLVMdgHPsf 4HDqw9UiaETqgkpSt7UJ47dvzqnnziZOZXbAqUi66eGAd24ef+n0sU+D2FbwNnnG J8ITh+1morKaHvpgzC4R+kC3yDsc5H6nfQMZGeqgWOT5J64GdqjaEunocOK1c+gU tzLtRLaasaja9IeOLN+2xNM1oP/T/DiGVJZrD8aYTC4snoEo3NM9l0S5vHw0YbP9 j7Jv1NLHjX7EngDEVZiTrEDTp/wZdowFghNZBtARllzG5/927g5BxB5WAlUv3hx6 n56E4ONW4t3GZHHCxldub1IzbOLiMnLTc80Mv+oP7MlW0XQIvAtRkU6sgcQNFmXm 5kwBXBR9CiA8RAz5yZJagNKmMHKbz4SQdIo5lg/shh0ZKedJTAFLPTufN/t8MNKg EV3HBd447yhjD+ApHSm3fl1+zw1oi6sTUBEYiYv6RT7a9ZBcyV61TBPQSjiSV25t 08m/UBfVCtxzABEBnFb5e98/VQ9Drm55Qk7fA6y8Cj3MjcMku5J8gGAdn10SYMRt 9Ak8YprhVk3PQgkFJnS0Rhbjc4uoV70TnpOkVRDhfzPW0SoNWK1QjIpQHgefAtEF vx9d789/KutXtE9YV24QDzxYnor6mbC96EzNK1oeiFaGeB9nhkVrNFE8QWT7VCWl 5wvDbjRE9e/jO6S7zSob =DAdJ -----END PGP SIGNATURE----- --KM+e2hnYAO+MCJ5e--