Date: Tue, 22 Jul 2014 20:45:43 -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: <20140723004543.GH29618@pwnie.vrt.sourcefire.com> In-Reply-To: <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org> References: <96C72773-3239-427E-A90B-D05FF0F5B782@freebsd.org> <20140720201858.GB29618@pwnie.vrt.sourcefire.com> <alpine.BSF.2.11.1407230017490.88645@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--6lXr1rPCNTf1w0X8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 i= s 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 applicati= ons=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 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 featur= es=20 > > (WITNESS, INVARIANTS, etc.) turned off to better simulate a production= =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 avera= ges. > > > > 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 l= ike 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 fragmentati= on of=20 > the address space. I'm not sure I have a specific application here in mi= nd --=20 > in the past I might have pointed out tools such as ElectricFence that ten= d to=20 > 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. >=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. 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 > I wonder if some equipment in the FreeBSD Netperf cluster might be used t= o=20 > help with performance characterisation -- in particular, very recent high= -end=20 > server hardware, and also, lower-end embedded-style systems that have mar= kedly=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-lev= el=20 > parallelism in the higher-end designs that can mask increases in instruct= ion=20 > 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). >=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. I'll take a look at that, too. Thanks a lot for your suggestions and feedback. Thanks, Shawn --6lXr1rPCNTf1w0X8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTzwW2AAoJEGqEZY9SRW7u/ZAP/3eiNNfWqYY5R/ZL+j98/amy GNeADbDO8OaPQRQaTYhQADU//XIbbf4mUFsj9SO9FPJxOka9h8UsBfNMF6jspnnw 2RAXvbnelXWlfLl1p+U0KE3umZUw1Ukm7IPs+KWwaaAlgaKcGEyOk9RQpzcNiqbD qDW5ubq8AGBvgSNWOOQGnc7G5IqegNScZxv78ZWwDV/c9I8g51sJySDEJjSE05bk QHSBDeNlg3+lJQH7NqRerH6GM532QueILCvVr5ARbiSvFufsYtvuHY3nI+eTnEko alNQVQ/ITmYZ/WWH0KP9sF8itS2+jcfuIo+LueETB11TBiRCtuneRtYBDNb/UaTs LDl1WcJ5RB0RoQpgUpPNSCkndhuilT7wARXKOYX3o9hWoEfu+xxkpmzo5aVVEs4t tjUfF3SuqiDTXXf6LvbQafpW1cX8gt1a6selBO7r417ANBdXpm1UN99kQrCfCBJj g4IDKBotb78xG4o+ES/YR6Je65O6CIRVt4tGZPSM5Ej4mdVIGjElTR05Wq7l5WmU utwJnWHSAwHnlFOSb8aR6TTF3OSxCdILS5gPeGbK6Jym9jcbjAv+PD6aeLMANUqn czC2gRLQ+Qpuu41o8Ti6AyN4toKJDFvP4RBQWK0xnGCaAtYU6SnW32TVpbhe0GrB 40+zyhUfD0Zy3phhq4vm =ErzN -----END PGP SIGNATURE----- --6lXr1rPCNTf1w0X8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140723004543.GH29618>