[RFC] ASLR Whitepaper and Candidate Final Patch

[Shawn Webb]

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.

Thanks,

Shawn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140722/7e474d0d/attachment.sig>