PIE on 64bit

[John Moser]

On 04/19/2013 08:25 AM, Matthias Klose wrote:
> Am 18.04.2013 20:25, schrieb John Moser:
>> Meant to go to list
>> On Apr 18, 2013 2:15 PM, "John Moser" <john.r.moser at gmail.com> wrote:
>>
>>> On Apr 18, 2013 2:07 PM, "Insanity Bit" <colintrexob at gmail.com> wrote:
>>>> On 64bit multiple services (pulseaudio, rsyslogd, many others) are
>>> shipping without Position Independent Code. On 32bit there is a potential
>>> performance hit for startup time... but there shouldn't be any performance
>>> hit (or negligible) on 64bit.
>>> There is a continuous performance hit of under 1% without
>>> -fomit-frame-pointer and under 6% with -fomit-frame-pointer on IA-32.  The
>>> impact is statistically insignificant (i got 0.002% +/- 0.5%) on x86-64.
>>>
>>> The performance hit on IA-32 only applies to main executable code because
>>> library code is PIC already.  This accounts for under 2% runtime, except in
>>> X where it used to be 5%.  That makes the overall impact 2% of 6% or
>>> 0.12%--which is non-existent if your CPU is ever at less than 99.88% load
>>> because you would swiftly catch up.
>>>
>>> In other words:  there is NO PERFORMANCE HIT for PIE in any
>>> non-laboratory, non-theoretical situation.  (Theo de Raadt argued this with
>>> me once, using the term "very expensive" a lot.  I built two identical
>>> Gentoo boxes and profiled them both extensively with oprofile.  It is
>>> exactly a theoretical cost, and the performance concerns come from people
>>> who have no clue what the execution flow of modern software looks like)
> I'm tired to repeat that there *is* a performance penalty.  Building the python
> interpreters with -fPIE results in about 15% slower benchmarks.  Building GCC
> with -fPIE slows down the build times by 10-20%.
>
> So maybe you want to have a python interpreter with -fPIE, accepting this
> performance penalty, and gaining some security?  But what else do you gain by
> building GCC with -fPIE besides forcing longer build times on developers?
On x86-64 PIC is handled fast natively with additional registers, and 
non-PIC has a higher penalty to load and execute (because of more RAM 
usage and so occasional page faults to read from swap, since the main 
executable .text is not shared).

What are your Python benchmarks?  Loading/unloading a program?  Most of 
Python's modules are *in* Python.

Do you mean to indicate that building gcc with a gcc built with -fPIE is 
slower, or that building gcc with -fPIE is slower?  The first is an 
actual legitimate test; the second is making gcc itself do more work 
during build.

Who ran these benchmarks?  What do they actually measure?

> I don't think that -fPIE is ready to be enabled by default, but maybe we need to
> think about a better or easier way to enable it. However the current method
> using the hardening-wrapper seems to work fine.
>
>    Matthias
>
>