[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5481CA94.4030504@gmail.com>
Date: Fri, 05 Dec 2014 10:09:08 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Offset2lib: bypassing full ASLR on 64bit Linux
On 05/12/14 09:37 AM, Hanno Böck wrote:
> On Fri, 05 Dec 2014 14:30:31 +0100
> Florian Weimer <fweimer@...hat.com> wrote:
>
>> On 12/05/2014 01:54 PM, Hanno Böck wrote:
>>> Most distros don't ship pic/pie executables by default. Why? I
>>> haven't done benchmarks, the saying is that this has a notable
>>> performance hit on 32 bit but almost none on 64 bit. If this is
>>> true then could we at least have all major distros enable it on 64
>>> bit?
>>
>> Copy relocations support has still be added to GCC. For x86_64, a
>> patch exists:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html
>>
>> Without that, there is still a performance impact.
>
> Interesting.
>
> Do you know the state of this? The thread indicates that the poster
> asked for review of his patch and never got one.
> Any gcc people here who could comment?
>
> Do you have numbers on the performance impact? Or some good ideas what
> would be reasonable benchmarking targets?
> As libraries are pic-compiled anyway from my limited understanding I
> think this only affects code in the main executables.
> I saw that chrome already ships pie-binaries, firefox doesn't.
> (Browsers seem like performance critical, so google seems to think it's
> no big performance deal).
The performance impact of PIE on x86_64 / ARM is usually negligible. If
the program does lots of global accesses in performance critical areas
then that GCC issue could have a significant impact. The issue would
have been fixed a *long* time ago if distributions used (full) ASLR. I
don't think performance bugs with an available fix are a compelling
argument against it.
Indirection to access a global in an *external library* is rarely going
to matter, especially considering that the libraries themselves are
already paying for -fPIC rather than just -fPIE. LTO will already fix it
within the application. There's also a significant performance hit for
thread_local from -fPIC with the default thread model but that doesn't
apply to -fPIE.
You're correct that dynamic libraries must already be built with -fPIC,
which is a superset of the -fPIE requirements.
Fedora and Debian put a lot of effort into using dynamic libraries
whenever possible. I haven't seen the performance issue ever come up,
even when they're unbundling a library that's special-cased to the
program (Firefox / cairo). It's strange to see the same people working
on unbundling arguing against PIE from a performance POV.
Mozilla has no excuse for not enabling PIE for Firefox, because 99% of
the code is in dynamic libraries already. It has no performance impact.
The only reason that we're not shipping PIE executables across the board
for x86_64 Arch Linux is the fact that upstream (GCC) hasn't provided a
good way to enable PIE by default. You either have to patch the
toolchain like Hardened Gentoo or make use of wrapper scripts.
The Debian wrapper scripts don't handle every special case, so there are
projects that break with them. IIRC, they don't special case -S or -E so
it breaks an autoconf test in the Firefox build. I rolled our own
wrapper scripts with more attention to these special cases but I still
need to actually propose that we start using them by default...
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
