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

[Mike Frysinger]

On 10 Mar 2016 01:00, Nix wrote:
> On 9 Mar 2016, Mike Frysinger uttered the following:
> > 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 ...
> 
> I think so, *if* we can be sure that arches that define
> _HAVE_STRING_ARCH_memcpy will never expand memcpy() to macros that
> sometimes call functions, but only to pure inline asm stuff. Since there
> is only one definer of that (x86), I'm not sure that's guaranteed...

i guess look at the other arch inlines to see what they do.  i honestly
don't know where or how well these APIs are defined.

> +  /* sbrk gives us zero'd memory, so we don't need to clear the remainder.
> +
> +     Use inlined asm implementation if available: otherwise, copy by hand,
> +     because memcpy() is stack-protected and is often multiarch too.  */
> +
> +#if defined _HAVE_STRING_ARCH_memcpy
>    memcpy (_dl_static_dtv[2].pointer.val, initimage, filesz);

should this also depend on SSP not being enabled ?
#if defined _HAVE_STRING_ARCH_memcpy || !defined <whatever SSP define>

otherwise, you'd want to use "#ifdef".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160310/7127b9df/attachment.sig>