Bug#552688: [hertzog@debian.org: Bug#552688: Please decide how Debian should enable hardening build flags]
On Thu, Jul 28, 2011 at 07:01:02PM +0200, Matthias Klose wrote:
> On 07/27/2011 04:09 PM, Kees Cook wrote:
> >- there needs to be a way to identify those architectures that are
> > "register starved", since those should _not_ get the PIE flags by
> > default (e.g. i386 should not get PIE, but amd64 should get PIE by
> > default). Right now if one uses hardening-wrapper, it's expected
> > that everything that can be enabled is enabled, so you gain PIE
> > even on i386 at the moment.
>
> please communicate the trade off even for amd64. It's measurable,
> and I don't see any value in slowing down cc1* for this.
Hopefully I have done this in one of the other emails now.
Do you have a specific test-case I can use for cc1? I cannot find my notes
on the Python benchmark you showed me before, so that would be handy too.
At the time, I only benchmarked i386 since I wanted to better understand
the scope of the slowdown there, under the assumption that everything was
better off than i386. :)
In the hardening bzr tree, I have some notes from i386 comparisons,
all with caches dropped before starting each run:
Inkscape converting a massive SVG to PNG, under 1%, same error:
inkscape Normal Hardened (with PIE)
1 48.163 48.503
2 48.227 48.535
3 48.267 48.647
4 48.335 48.431
5 48.199 48.587
avg 48.2382 48.5406 diff: 0.63%
error 0.20% 0.22%
gfsplit chopping up 1M random data into 50-of-100 splits, was faster,
but within the normal error, so hard to say:
gfsplit Normal Hardened (with PIE)
1 32.226 32.022
2 32.118 32.042
3 32.026 32.026
4 32.178 31.996
5 31.998 32.054
avg 32.1092 32.028 diff: -0.253%
error 0.36% 0.08%
Nexiuz timedemo, under 1%, though the hardened error was high:
nexuiz Normal Hardened (with PIE)
1 66.680 68.113
2 66.802 66.930
3 66.758 67.030
4 66.728 67.051
5 66.859 67.037
avg 66.7654 67.2322 diff: 0.70%
error 0.14% 1.31%
I don't have the Python benchmark unfortunately, but it was impressively
nasty. Something like 15% slower. So while many things do just fine,
some show amazingly bad speed changes on i386. But, I haven't seen the
benchmarks for amd64 and armel. I'm very curious them, given that even on
i386 most things are under 1% (and when these benchmarks were done,
they also included _FORTIFY_SOURCE and stack-protector and everything
else in the speed delta).
-Kees
--
Kees Cook @debian.org
Reply to: