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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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: > > > > >> - It is yet undetermined what the performance effect will be, and it is not > > >> clear (but seems likely from past measurements) if there will be a > > >> performance hit even when ASLR is off. -Apparently there are applications > > >> 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 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). > > > > > > In each of these three scenarios, I'll have the kernel debugging features > > > (WITNESS, INVARIANTS, etc.) turned off to better simulate a production > > > system and to remove just one more variable in the tests. > > > > > > I'll run unixbench ten times under each scenario and I'll compute averages. > > > > > > Since this is an older laptop (and it's running ZFS), these tests will take > > > a couple days. I'll have an answer for you soon. > > > > Hi Shawn: > > > > Great news that this work is coming to fruition -- ASLR is long overdue. > > > > Are you having any luck with performance measurements? Unixbench seems like a > > good starting point, but I wonder if it would be useful to look, in > > particular, at memory-mapping intensive workloads that might be affected as a > > result of changes in kernel VM data-structure use, or greater fragmentation of > > the address space. I'm not sure I have a specific application here in mind -- > > in the past I might have pointed out tools such as ElectricFence that tend to > > increase fragmentation themselves. > > 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. > > 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. > > > > > Also, could you say a little more about the effects that the change might have > > on transparent superpage use -- other than suitable alignment of large > > mappings, it's not clear to me what effect it might have. > > 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. > > > > > I wonder if some equipment in the FreeBSD Netperf cluster might be used to > > help with performance characterisation -- in particular, very recent high-end > > server hardware, and also, lower-end embedded-style systems that have markedly > > different virtual-memory implementations in hardware and software. Often > > those two classes of systems see markedly different performance-change > > characteristics as a result of greater cache-centrism and instruction-level > > parallelism in the higher-end designs that can mask increases in instruction > > count. > > 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 > > 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). > > > > > I think someone has already commented that Peter Holm's help might be > > enlisted; you have have seen his 'stress2' suite, which could help with > > stability testing. > > 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 [-- Attachment #2 --] -----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-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140724175704.GT29618>