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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org