[PATCH 05/14 v6] Open-code the memcpy() at static TLS initialization time.

[Nix]

On 24 Jun 2016, Florian Weimer said:

> On 06/24/2016 03:10 PM, Nix wrote:
>> On 24 Jun 2016, Florian Weimer said:
>>> I looked at the memcpy.c and wordcopy.c implementations, and I do not
>>> see why these functions would need the stack protector. They should
>>> not have addressable local variables, they should all be in registers.
>>
>> Now we're depending on the details of compiler register allocation for
>> security? What if the compiler changes?
>
> The stack protector already has such a dependency on compiler internals. I'm not too worried about this aspect.

The stack protector is *part* of the compiler, though. That's a bit
different, in my eyes.

>>> Anyway, if the above analysis is right, it should be safe to disable
>>> stack protector for functions such as memcpy (essentially doing
>>> manually what -fstack-protector-strong does automatically). This would
>>> be my preferred approach here.
>>
>> ... which would mean we could drop this patch, too.
>
> Wouldn't you have to supply $(no-stack-protector), for the sake of the dynamic linker?  Or does the rtld recompilation take care of
> that?

Yeah, that's handled by the elide-stack-protector stuff in elf/Makefile.
(If we had to de-stack-protect everything ld.so used by hand, the patch
really would be unmaintainable.)

-- 
NULL && (void)