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.mo...@gmail.com> wrote:
On Apr 18, 2013 2:07 PM, "Insanity Bit" <colintre...@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
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
