Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 2014 22:00:02 -0500
From:      Pedro Giffuni <pfg@freebsd.org>
To:        Shawn Webb <lattera@gmail.com>
Cc:        PaX Team <pageexec@freemail.hu>, Oliver Pinter <oliver.pntr@gmail.com>, Robert Watson <rwatson@FreeBSD.org>, Bryan Drewery <bdrewery@FreeBSD.org>, freebsd-arch@freebsd.org
Subject:   Re: [RFC] ASLR Whitepaper and Candidate Final Patch
Message-ID:  <112E989D-607B-47AC-8942-0FB049DA6C3D@freebsd.org>
In-Reply-To: <20140724175704.GT29618@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> <20140724175704.GT29618@pwnie.vrt.sourcefire.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Il giorno 24/lug/2014, alle ore 12:57, Shawn Webb <lattera@gmail.com> ha =
scritto:

> 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 =
applications=20
>>>>> that will segfault (?).
>>>>=20
>>>> 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).
>>>>=20
>>>> In each of these three scenarios, I'll have the kernel debugging =
features=20
>>>> (WITNESS, INVARIANTS, etc.) turned off to better simulate a =
production=20
>>>> system and to remove just one more variable in the tests.
>>>>=20
>>>> I'll run unixbench ten times under each scenario and I'll compute =
averages.
>>>>=20
>>>> 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 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 =
affected as a=20
>>> result of changes in kernel VM data-structure use, or greater =
fragmentation 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 tend 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 =
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.
>>=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 =
high-end=20
>>> server hardware, and also, lower-end embedded-style systems that =
have markedly=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-level=20
>>> parallelism in the higher-end designs that can mask increases in =
instruction=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
> The unixbench results are in. The overall scores are below.
>=20
> ASLR Disabled: 456.33
> ASLR Enabled:  357.05
> No ASLR:       474.03
>=20
> I've uploaded the raw results to
> http://0xfeedface.org/~shawn/aslr/2014-07-24_benchmark.tar.gz
>=20
> 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.
>=20

The effect of the available RAM and/or age of the system is
independent of ASLR being on or off si I think the results are valid.

As Robert said, the particularly bad result is the effect of having ASLR
disabled vs not having the patch at all. The priority should certainly =
be
to fix this.=20

The effect of ASLR seems significant, I did expect it less but it is =
something
that can be expected. People that enable ASLR have to be aware that =
there
are consequences performance-wise. A further effect that hasn=92t been =
quantified
but could be obtained from the raw data is the standard deviation. I =
would expect
that the randomization induced from using ASLR will cause an important =
increase
in the standard deviation and that performance will be basically =
unpredictable.

The last issue is a show stopper from enabling ASLR by default but the =
first
issue is a show stopper from committing the patch at all :(.

Of course, all just IMHO.

Pedro.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?112E989D-607B-47AC-8942-0FB049DA6C3D>