On 05/05/11 05:26, Gaetan Bisson wrote:
[2011-05-05 01:29:17 +1000] Allan McRae:
The plan is to add "-fstack-protector-all -D_FORTIFY_SOURCE=2 --param=ssp-buffer-size=4" to our C{XX}FLAGS and "-Wl,-z,relro" to our LDFLAGS.
Using these flags to build random packages, they appear to increase the typical binary size by roughly 6%. That's not too bad but could you say a bit more on the pros of enabling them for me and others who weren't devs when this was first discussed?
What these flags do: -D_FORTIFY_SOURCE=2 Adds a very, very lightweight buffer overflow protection to some memory and string functions. As much as possible is checked at compile time. See http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html for the details. -fstack-protector More buffer overflow prevention. This uses the canary approach to detecting buffer overflows so has some minor runtime overhead but does prevent an entire class of attacks (and a common class...). See http://en.wikipedia.org/wiki/Buffer_overflow_protection#GCC_Stack-Smashing_P... . -fstack-protector does this for strings only. Note I have dropped the "-all" at the end of "-fstack-protector" after discussion with several people regarding the overhead and other potential issues. --param=ssp-buffer-size=4 The buffer size flag sets the size of the array required before stack protection is activated. The default is 8 but Fedora and Suse (and possibly Ubuntu) all adjust this to 4, as does Hardened Gentoo and HLFS. -Wl,-z,relro Puts commonly exploited ELF structures into (sort of...) read-only locations. The other LDFLAGS I suggested: -Wl,-O1 Optimisation level for ld (just like the gcc flags) -Wl,--sort-common Prevents gaps between symbols due to alignment constraints. This presumably results in increased efficiency in the layout and the associated performance gain. Both those should really have been added when we first added LDFLAGS. Allan