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

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

Hi lists,

So here are the rest of the benchmarks I have run so far. I can provide 
more detailed results to whoever would like to analyze them; feel free 
to ask.

==== sysbench ====

I ran 2 benchmarks:
- the one benchmarking threads creation/destruction.
- the "OLTP" one (online transaction processing), with mysql as the db
server (I can provide the my.cnf if you want). It simulates a typical 
online database workload.

The graphs:

http://www.netbsd.org/~jym/

What I can say:
- for low number of threads, the highest loss is 4% (== SSP is 4%
'slower' than NO SSP).
- for high concurrency (100+ threads running), it is more difficult to
distinguish one from the other. There is no clear margin.

Note that my host is a P4M 2GHz (centrino, laptop, i386 only): no SMP, 
only one core. Concurrency is not something you would expect with such a 
machine.

==== pure build.sh distribution ====

4 runs (2 with SSP enabled kernel, 2 without SSP kernel).
Each time, the OBJDIR and DESTDIR were moved away, and the computer
rebooted. No -j used.

no-ssp kernel    6254.48 real      5088.01 user       786.01 sys
no-ssp kernel    6415.72 real      5097.60 user       789.96 sys
ssp kernel       6272.31 real      5094.03 user       791.23 sys
ssp kernel       6181.41 real      5090.63 user       794.36 sys

Like abs@ suggested in a private mail, and like I am planning to do, I
will run the same benchmarks against a pure NO-SSP userland and kernel,
just to draw a baseline.

For reference, the libmicro benchmarks:

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

IMHO, the 5% penalty is exaggerated. It does not look like to be 
systematic, and moreover, subject to context (== not easily 
reproducible); I am not sure that SSP overhead is that much significant.

HTH

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