On 12/05/10 16:49, Jan de Groot wrote:
On Wed, 2010-05-12 at 12:35 +1000, Allan McRae wrote:
Hi,

We have a bug report asking to enable stack-smashing protection in our
package building.  Looking at the overhead estimates by other distros
that use it, overall it appears fairly minimal (OpenBSD says 1.3% on
average).  There used to be some build issues (see bottom of this page
for Ubuntu report: https://wiki.ubuntu.com/GccSsp), but I am not sure of
the current status.  Also, it can be disabled with -fno-stack-protector
if needed.

I am in favour of doing this.  I think adding -fstack-protector is
enough as that adds protection to only functions "vulnerable" to buffer
overflows (as defined by gcc...  mainly character arrays) while
-fstack-protector-all adds it to all functions.

We should maybe also add -D_FORTIFY_SOURCE=2.  This detects some buffer
overflows compile time and others at run time.  It was designed to have
minimal runtime overhead.

Any opinions?

Given the fact that GCC 4.5 produces broken binaries with software that
needs -fno-strict-aliasing (busybox comes to mind, but also others), I
don't think it's good to introduce such a change now. Our toolchain
should get fixed before we attempt to add more features to our compiler
flags.


There is a fix on the gcc bug tracker but I am waiting for it to be backported to gcc-4.5. If it has not been done by the next toolchain rebuild (I expect in the next week), I will backport it myself.

Anyway, it was not going to happen immediately. Sadly, nothing of this sort can be achieved in under a multiple month timeframe around here. But it could possibly happen with the next pacman release given that makepkg.conf will need changed. Hence starting discussion now. Well actually I started it a month ago on the bug tracker but only one of the five people I assigned answered my request for comments...

The reason I bought this up again now is that there is a glibc release tagged and the glibc package will need preparation for both this and the new shared library stripping behaviour in makepkg so I though I would begin this now if comments seemed positive.

Allan

Reply via email to