Date: Thu, 24 Jul 2014 13:57:04 -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: <20140724175704.GT29618@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
--iiZKCn1f/U0ES2iY 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. The unixbench results are in. The overall scores are below. ASLR Disabled: 456.33 ASLR Enabled: 357.05 No ASLR: 474.03 I've uploaded the raw results to http://0xfeedface.org/~shawn/aslr/2014-07-24_benchmark.tar.gz 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. Within the last day, I have made some changes to clean up the code backing our ASLR implementation that would enhance the performance when ASLR is enabled. I'll re-run the tests when ASLR is enabled starting tonight and I'll have a new set of results tomorrow. I'll also give ElectricFence a try. Those results will come later. Thanks, Shawn --iiZKCn1f/U0ES2iY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0UjwAAoJEGqEZY9SRW7upXQP+gMuiSjxgS1WzW+c9rTRPG4J ocLpIDYd0HabUwx/q5VC0hPJFF/svikEn4VGa+/Avm47WMA9s00MHcW7B5cvz35R h6hXZHXom3bEd4FDUAqx0keMbQTPdHe4OUNcbF1EvX1hhslcEfPk5U8xIaMd23H1 tXeM91ADGO9gl3HY1KizKRSFtX9u8GLpUmVBEhkLTVpgYHxnuDTstZC7Yekrkmsd MXePHEMUeXJXIrwt/TEgFepIIY7eSTsL40dMtRZHXEtsP1J+wb/aA5rawfwd5kU3 1mrRrs5Gp7YN4YvFG/rtGrIbBVH0Yg9SeXW54GdImS6wJsn8dWcgFYkQ0tVQr7Ee EndVVYZMeZDfTZseloxHMeELa+/93VqVyPKKvsUTxncC2yelKARGSqT9DbrUKiWS KxqwpG3vL9m4tNmDy9ikOEJvwSnMzKz+4jP0bKAQYPcf3oSgQHsJTenSKWJ46r7U FCuS6WfP3GSt2bCT2WrxeQptAtR6L19aMdO+s+G4V+vkJ351G2SapUhewgzJPsKD x6eJCpwVymOWPxfWU2a46Kd7MJybIvJCgctet8BUnN3v9pFO/frQTjmi6PydOhwX RYkNrVgiZhrF09/BmxS0BCQcBEfME2sw6xbxZeDXyx6plmbFOPVuVoUBJ/3uLkXO tmz8E55e/GDBgPKdkPd4 =FgZY -----END PGP SIGNATURE----- --iiZKCn1f/U0ES2iY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140724175704.GT29618>