[gentoo-amd64] Re: Disable SPP On GCC-4.8.3

[Duncan]

Frank Peters posted on Mon, 16 Jun 2014 20:18:59 -0400 as excerpted:

> GCC-4.8.3 is now in the portage tree and it enables SSP, or Stack
> Smashing Protection, by default.
>
> I don't want SSP.  It can be disabled using the -fno-stack-protector
> flag.
>
> Checking the portage use.local.desc file, it seems a better way to
> disable SSP is to specify the "nossp" USE flag for gcc.  With this USE
> flag set, gcc will be built without SSP.
>
> However the "nossp" USE flag has some sort of warning attached to it in
> the use.local.desc file:
>
> sys-devel/gcc:nossp - Disable SSP support (NOT FOR GENERAL USE)
>
> What does this mean?  Is it safe to use the "nossp" USE flag to build
> gcc?

Based on the discussions on the dev list, I believe the nossp USE flag 
was originally only for specific-case usage in the hardened profiles, and 
now will likely be expanded to the archs (like hppa I believe) where ssp 
doesn't work.  As such, I'd consider it quite likely that the flag will 
eventually be masked on general profiles, since the idea is to make gentoo 
a bit safer by enabling it in general, and disabling it only on archs 
where it is known not to work (hppa I believe, among others).

While it is of course possible to unmask such a flag and then use it, I'd 
consider strongly before you do as that puts you FAR out of tested gentoo 
mainstream.

That said, in theory at least it should "just work", since this is a 
change to the /gentoo/ gcc spec-file defaults, not upstream, and turning 
it off is simply turning off a newly default feature that has until now 
been off unless you specifically turned it on.

But I'd still strongly recommend adding the -fno-stack-protector to your 
CFLAGS, as that will continue to be supported by gentoo, while messing 
with gcc's nossp flag is not recommended and may result in bugs being 
closed INVALID or NEEDINFO (duplicate with the flag toggled before 
reopening), etc, as a result.

/That/ said, there's actually three levels of ssp now, with this one the 
lowest level, dropping performance very little while focusing protection 
on the functions that are easiest to abuse AND to protect.  Actually, as 
the news item states, the middle (strong but not all) option is the 
planned default for gcc 4.9.  That being the case, I'd at /least/ 
recommend this lower level of protection on at least the most critical 
functions where the performance cost is quite low in comparison to the 
benefit.  If you want to disable the strong-but-not-all default when it 
comes in 4.9, OK, but I'd suggest at least keeping this minimal threshold 
of protection, particularly since it /will/ be the default now and thus 
there should be if anything fewer problems with it than not.

But it's you're machine, and we'd not be gentooers if we didn't want to 
be king over the configuration of our own machines, so go to it if you 
are sure.  =:^)  Just do your research (perhaps you already have) and 
know exactly why you're doing it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman