El jue, 09-01-2014 a las 17:06 -0500, Anthony G. Basile escribió: > On 01/09/2014 04:57 PM, Pacho Ramos wrote: > > El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió: > >> Hi > >> > >> Some time ago we discussed that we should enable stack smashing > >> (-fstack-protector) by default. So we opened a bug to track this [1]. > >> The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, > >> ppc, > >> ppc64 and arm will be affected by this change. > >> > >> You can turn off ssp by using the nossp USE flag or by adding > >> -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same > >> patch as Debian/Ubuntu but with some Gentoo fixes. > >> > >> The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and > >> ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard(). We will > >> make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn > >> it on or off with hardened_gcc_works() that will make some sanity checks. > >> > >> /Magnus > > What are the advantages of disabling SSP to deserve that "special" > > handling via USE flag or easily disabling it appending the flag? > > > > Thanks a lot for the info :) > > > > > > There are some cases where ssp could break things. I know of once case > right now, but its somewhat exotic. Also, sometimes we *want* to break > things for testing. I'm thinking here of instance where we want to test > a pax hardened kernel to see if it catches abuses of memory which would > otherwise be caught by executables emitted from a hardened toolchain. > Take a look at the app-admin/paxtest suite. > >
OK, thanks a lot, I was wondering if I would need to disable SSP on some of the machines I maintain for some reason. Looks like keeping it enabled is preferred instead ;)
