Re: HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Joerg Sonnenberger wrote:
> On Wed, Nov 11, 2009 at 04:55:07PM +0000, Matthias Scheler wrote:
> > SSP will result in a slowdown of about 5%, please read this thread
> > for more details:
>
> Just to insert some hard numbers into this thread.

Same for me:

I just finished the generation of the comparison file for libmicro 
benchmark against SSP. For those that do not know about libmicro, see [1].

Hardware:
Pentium M 2GHz (Dothan) (686-class), id 0x6d6
1GB RAM
80GiB 5400 RPM IDE disk

4 runs against libmicro:
- 2 runs with full SSP system (USE_SSP=yes),
- 2 runs with a "semi-SSP" system (everything was SSP compiled except 
kernel and modules). All runs from a very minimal environment (~ single 
user, but with network enabled).

Benchmark are here:

http://www.netbsd.org/~jym/comparison-1.html
http://www.netbsd.org/~jym/comparison-2.html


General:
- everything relating to I/O or memory ops (mmap, pipes, sockets, ...) 
stay pretty much unaffected by in kernel enabled SSP: sometimes the 
NOSSP kernel is faster, sometimes the SSP kernel is. The difference 
stays between ~1-2%.
- I can't reproduce the bad results of the cascading flock() calls from 
the first run. Probably context specific.

Specific:
- slower writev(2) calls when writing NULL chars to /dev/null, with 
increasing number of iovec structs. Given how short this operation is 
expected to be, there could be resolution inconsistencies here.
- pthread creation (pthread_create) seems to become slower under SSP, by 
a 10% margin. Reproducible.
- getcontext(2) by a 38% margin, which is quite important. Also 
reproducible. Small times, could be exposed to resolution inconsistencies.

I am planning to run more thread-oriented benchmarks.

[1] http://pkgsrc.se/wip/libmicro

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost