Date: Wed, 23 Jul 2014 17:47:08 -0400 From: Shawn Webb <lattera@gmail.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: PaX Team <pageexec@freemail.hu>, Pedro Giffuni <pfg@freebsd.org>, Oliver Pinter <oliver.pntr@gmail.com>, Bryan Drewery <bdrewery@FreeBSD.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch Message-ID: <20140723214708.GO29618@pwnie.vrt.sourcefire.com> In-Reply-To: <20140723004543.GH29618@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140723214708.GO29618>