Re: Introducing security hardening features for Lenny

["brian m. carlson" <sandals@crustytoothpaste.ath.cx>]

On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:
> On Tue, Jan 29, 2008 at 10:31:48PM +0000, Moritz Muehlenhoff wrote:
> > There are certainly performance trade-offs involved and the final
> > selection of features will depend on the testing of the respective
> > maintainers (testing should be eased by hardening-wrapper).
>
>  I understand. To be fair, I'm worried in the implications of the SSP,
> FORTITY_SOURCES and PIE proposals. Others looks fine, but those three
> may have very important performance issues embedded.
>
> * PIE is just IMHO not an option on x86 :/

If you use shared libraries, you already have this performance hit, and 
if you want to use %ebx in non-PIC code, you have to save and restore it 
around each shared-library function call.  Also note that x86 has other 
problems (namely the 387) that make it unsuitable as a serious 
architecture.

>  Though probably someone should come up with some benchmarks. The usual
> culprits (multimedia libraries, html renderers, xml processors, …) all
> provide easily deployed bench, and before we go any further I'd like to
> see some numbers.

And now for some numbers, on an amd64 machine (/proc/cpuinfo at [0]), 
crypto code with heavy optimization in a shared library.  All object 
files (including for the executable) are compiled with -fPIC, because 
I'm lazy.

Performance without protection:

MD4: 335544320 bytes in 0.745s (429.667 MiB/s)
MD5: 335544320 bytes in 1.055s (303.452 MiB/s)
RMD160: 335544320 bytes in 1.757s (182.169 MiB/s)
SHA1: 335544320 bytes in 1.801s (177.693 MiB/s)
SHA256: 335544320 bytes in 3.519s (90.928 MiB/s)

With -fstack-protector only:

MD4: 335544320 bytes in 0.748s (427.999 MiB/s)
MD5: 335544320 bytes in 1.056s (302.979 MiB/s)
RMD160: 335544320 bytes in 1.751s (182.744 MiB/s)
SHA1: 335544320 bytes in 1.804s (177.348 MiB/s)
SHA256: 335544320 bytes in 3.515s (91.028 MiB/s)

With -D_FORTIFY_SOURCE=2 only:

MD4: 335544320 bytes in 0.745s (429.670 MiB/s)
MD5: 335544320 bytes in 1.053s (303.846 MiB/s)
RMD160: 335544320 bytes in 1.756s (182.225 MiB/s)
SHA1: 335544320 bytes in 1.794s (178.330 MiB/s)
SHA256: 335544320 bytes in 3.514s (91.057 MiB/s)

With -fPIE -pie only:

MD4: 335544320 bytes in 0.741s (431.703 MiB/s)
MD5: 335544320 bytes in 1.052s (304.173 MiB/s)
RMD160: 335544320 bytes in 1.755s (182.381 MiB/s)
SHA1: 335544320 bytes in 1.797s (178.104 MiB/s)
SHA256: 335544320 bytes in 3.517s (90.996 MiB/s)

With all three features:

MD4: 335544320 bytes in 0.744s (429.978 MiB/s)
MD5: 335544320 bytes in 1.058s (302.479 MiB/s)
RMD160: 335544320 bytes in 1.758s (182.071 MiB/s)
SHA1: 335544320 bytes in 1.793s (178.471 MiB/s)
SHA256: 335544320 bytes in 3.520s (90.896 MiB/s)

In conclusion, there is no appreciable performance hit on any algorithm.  
Note that these are all hash algorithms, but they all make heavy use of 
memcpy, and are extremely CPU-intensive.

Code available upon request.

[0] https://crustytoothpaste.ath.cx/machines/lakeview

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature