This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |