[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 Cook                                            @debian.org

Reply to: