On Mon, Jun 4, 2012 at 11:09 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 06/04/2012 11:01 AM, Jakub Jelinek wrote:
>>
>> On Mon, Jun 04, 2012 at 10:34:21AM +0200, Florian Weimer wrote:
>>>>>
>>>>> +This protection mechanism is only a last resort. As a programmer, you
>>>>> +must not rely on its presence, but use explicit buffer length checks
>>>>> +to avoid buffer overflows. GCC may not be able to determine buffer
>>>>> +sizes accurately, and the accuracy depends on compiler version and
>>>>> +optimization level (currently, at least @option{-O2} is required).
I think "accurately" is a wrong word here - doesn't that suggest it might
get "wrong"? The answer should always be conservatively correct, so
it might just be not as constrained as it should. So I think you need
to elaborate on "accurately" here.
>>>>
>>>> That isn't true, at -O1 or -Os it should work just fine too, and
>>>> to some extent on the compiler side even at -O0.
>>>
>>>
>>> Fold needs to run. Without it, __builtin_object_size constantly
>>
>>
>> Folding is performed at all optimization levels.
>> The objsz pass is only performed at -O1 and above (as it is among
>> optimization passes).
>
>
> Ah, interesting, thanks. I think before we can apply this patch, we have to
> benchmark its impact on compile time. I'll try to do that by compiling GCC.
> Or are there better benchmarks for such a purpose?
>
> I guess libc should remove the check for optimization, even though the
> fortify checks interfere with debugging a bit (because you have to set
> breakpoints on different libc symbols).
>
> What about my documentation patch for GCC?
>
>
> --
> Florian Weimer / Red Hat Product Security Team
