Re: [gentoo-dev] Re: Improve the security of the default profile

[Richard Yao]

On 09/12/2013 11:03 AM, Richard Yao wrote:
> On 09/10/2013 09:17 PM, Rich Freeman wrote:
>> On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@g.o> wrote:
>>> 1. The kernel expects -fno-stack-protector to be the default. What will
>>> the effect be on kernel configuration once -fstack-protector is the default?
>>
>> Nothing, since the kernel build system doesn't source make.conf.  If
>> somebody creates an ebuild that actually installs a kernel then it
>> might be an issue, though it could be filtered if it is a problem.
>
> My understanding is that this change would be made to GCC's spec files,
> which affects everything that uses GCC.
>
>>>
>>> 2. We should make sure that -fno-stack-protector is a supported CFLAG.
>>> This will make it easier to handle complaints from the vocal minority of
>>> our user base that want every last percentage point of performance.
>>
>> No reason that it would be any less supported than -fstack-protector
>> already is.
>
> Just making certain.
>
>>>
>>> 3. I would like to point out that we are talking about deviating from
>>> upstream behavior and everyone is okay with it. Anyone who thinks we
>>> should stick to upstream when it is not good for us should speak now or
>>> risk being asked "where were you when..." whenever they try to use
>>> upstream as an excuse to hold back progress. ;)
>>
>> I don't really see this as an issue - in general maintainers are
>> expected to accommodate reasonable CFLAGS.  This doesn't mean that
>> arbitrary CFLAGS are "supported" so much as bugs should be taken
>> seriously if they're really bugs.  If -fstack-protector causes serious
>> problems and this is inherent to the nature of the package/etc then
>> just filter it.  If it causes problems because upstream isn't doing
>> things right, then this is no different than how things were 10 years
>> ago when we were stomping out amd64 issues left and right (not working
>> on amd64 wasn't a reason to mask a package for x86, but we didn't
>> accept "upstream doesn't care about amd64" as an excuse).
>>
>> Staying close to upstream is a good philosophy in general.  I don't
>> think that means that we can't have reasonable CFLAGS.  Otherwise we
>> wouldn't set CFLAGS at all and would just use whatever defaults the
>> upstream build system applies.  We're a distro - doing integration
>> work is a value-add, not a sin.  If we aren't doing integration, then
>> users might as well just do Linux-from-scratch.
>>
>> Rich
>>
>
> Past events have led me to think that we are sometimes too dependent on
> upstream for guidance.  I have certainly deviated from upstream whenever
> it made sense and the results have been fairly positive. I am not saying
> that acting for the best interests of Gentoo is mutually exclusive with
> collaboration with upstream, but I am saying that the two sometimes
> conflict. This being one of them. I am taking this opportunity to point
> out that what is best for Gentoo should come first and that it is okay
> to make decisions on our own.
>

I just checked the kernel's makefiles. It does pass -fno-stack-protector
when the option is disabled. Therefore a GCC spec file change will not
have cause GCC to generate kernels that differ from their .config files.