Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.

[Pacho Ramos]

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 ;)