Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

[Florian Weimer <fweimer at redhat dot com>]

On 09/10/2015 06:30 PM, Martin Sebor wrote:
> On 09/09/2015 09:58 AM, Florian Weimer wrote:
>> On 09/08/2015 05:45 PM, Jonathan Wakely wrote:
>>
>>>> I doubt we can achieve the complexity goals in all cases.  I expect
>>>> that
>>>>
>>>>   for (int i = 0; i < 10000; ++i) {
>>>>     vector[i];
>>>>   }
>>>>
>>>> is optimized away in default mode, but with _GLIBCXX_ASSERTIONS, it is
>>>> not.
>>>>
>>>> The last time I looked at this, GCC was unable to move bounds checks
>>>> out
>>>> of loops.
>>>
>>> Maybe we don't want to make _FORTIFY_SOURCE imply _GLIBCXX_ASSERTIONS
>>> then, so they can be enabled independently. We don't have to make that
>>> decision right away.
>>
>> I think we should try with _FORTIFY_SOURCE first.  The above case looks
>> rather artificial.  If there is a visible performance impact, maybe we
>> can get the compiler to eliminate the vector bounds checks in many cases.
> 
> There is quite a bit of documentation of _FORTIFY_SOURCE that explains
> its effect on user code.

I think there are only random blog articles discussing aspects of it,
most of them slightly incorrect or outdated.

> People who have read the documentation and
> used the macro to achieve the effect might find the secondary effects
> on libstdc++ surprising and unwelcome.

I think we should ask Fedora, Debian and others if they want to enable
the new libstdc++ checks as part of their standard hardening features.
If the answer is yes, we should tack it onto _FORTIFY_SOURCE, so that
they do not have to audit all their package build processes to include
the additional preprocessor #define.

This discussion comes up every time we make *any* change to
_FORTIFY_SOURCE.  I'm not sure if it is that helpful because I haven't
seen much use of _FORTIFY_SOURCE outside distribution defaults.  If
distributions are indeed the target audience for _FORTIFY_SOURCE, and
they want the additional hardening, I don't think it's necessary to
split it off (but it certainly makes sense to have a way to turn it off
separately, if only to show that a particularly performance issue is not
caused by the new hardening feature).

-- 
Florian Weimer / Red Hat Product Security