Re: [PATCH 05/18] Open-code the memcpy() at static TLS initialization time.

[Mike Frysinger <vapier at gentoo dot org>]

On 08 Mar 2016 13:50, Nix wrote:
> 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).
> 
> So we have two real options: hack up the guts of posix/memcpy.c and
> */wordcopy.c so that they can be #included (renamed and declared static)
> inside libc-tls.c, or simply open-code the memcpy().  For simplicity's
> sake, this patch open-codes it, on the grounds that static binaries are
> relatively rare and quasi-deprecated anyway, and static binaries with
> large TLS sections are yet rarer, and not worth the complexity of hacking
> up all the arch-dependent wordcopy files.

can we utilize _HAVE_STRING_ARCH_memcpy here ?  the string includes will
sometimes provide inlined asm versions ...
-mike

Attachment: signature.asc
Description: Digital signature