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

[Florian Weimer]

On 06/24/2016 03:10 PM, Nix wrote:
> On 24 Jun 2016, Florian Weimer said:
>
>> On 06/07/2016 01:06 PM, Nix wrote:
>>> From: Nick Alcock <nick.alcock@oracle.com>
>>>
>>> This one is a bit nasty.  Now that we are initializing TLS earlier for
>>> the stack canary's sake, existing memcpy() implementations become
>>> problematic.  We can use the multiarch implementations, but they might
>>> not always be present, and even if they are present they might not always
>>> be in assembler, so might be compiled with stack-protection.  We cannot
>>> use posix/memcpy.c without marking both it and */wordcopy.c as non-stack-
>>> protected, which for memcpy() of all things seems like a seriously bad
>>> idea: if any function in glibc should be stack-protected, it's memcpy()
>>> (though stack-protecting the many optimized assembly versions is not done
>>> in this patch series).
>>
>> Some of the pathnames in this explanation appear to be incorrect.
>
> Oh, it's string/memcpy.c, isn't it? Sorry.

Yes, that seems better.

>> 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.

>> but the memory looks like this (addresses increase from bottom to top,
>> so the stack grows downwards on most architectures (except HPPA)):
>
> You see, there are "except"s creeping in already :) every one is a
> possible mistake...

HPPA is just very special (and very, very dead).

>> 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?

Thanks,
Florian