This is the mail archive of the 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]

--enable-stack-protector for glibc, v4, now with arm

This is version 4 of the stack-protected glibc patch, incorporating all review
comments to date (unless I missed some), and adding a degree of arm support
(i.e. "I know nothing about the platform but the tests passed").

Still no changelog citing bug 7065: I'm not confident enough that things won't
change, but I'd be more confident if someone could look at patch 15 in this
series and tell me why on earth it's even necessary (which it definitely is).

It's not rebased and is still against glibc head as of a week ago,

Tested with these flag combinations on {i686,x86_64)-pc-linux-gnu:

--enable-omitfp --enable-stack-protector=all
--enable-stackguard-randomization --enable-stack-protector=all
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=strong
--enable-omitfp --enable-stackguard-randomization --enable-stack-protector=all

Tested with with these flag combinations on sparc{32,64}-pc-linux-gnu:

--enable-stackguard-randomization --enable-stack-protector
--enable-stackguard-randomization --enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=all

Tested with these flag combinations on armv7l-unknown-linux-gnueabihf (it
happened to have GCC 4.8, so -strong wasn't available):

--enable-stackguard-randomization --enable-stack-protector-all

No failures are observed that are not also observed on an unpatched glibc with
the same flag combinations, other than localplt (due to the new __stack_chk_fail
PLT, which I'd suggest is desirable: it seems like something people might
reasonably want to interpose, and interposing it will have no performance

On the copyright assignment front, I am informed that Oracle has a blanket
assignment on file for glibc work, so I don't need to do anything.

Overview of changes in this posting:

 - use inhibit_loop_to_libcall to prevent GCC folding our open-coded memcpy()
   in static TLS setup back into a (prohibited) libcall again

 - introduce new inhibit_stack_protector that turns off -fstack-protector for a
   single function, and use it to stack-protect only the necessary functions
   within nptl: most of nptl-init.c, pthread_mutex_cond_lock.c and
   pthread_mutex_unlock.c are now protected.

 - De-stack-protect all ifunc resolvers: they're called before the stack canary
   is initialized in the dynamic-linking case, so must never be stack-protected.
   (How it worked before on x86 and sparc I have no idea, but on arm, it fails.)

 - stack-protected glibc now passes its tests on armv7l-unknown-linux-gnueabihf
   (an odroid c1, because I already had one sitting upstairs being a home

Remaining mysteries:

 - In patch 15, I have no understanding of why __pthread_mutex_unlock_usercnt()
   and __pthread_mutex_cond_lock_adjust() are special: yes, they're called
   directly from assembler, but that shouldn't be a problem: -fstack-protector
   doesn't change the function-call ABI!  Nonetheless, it *is* a problem, and
   this is definitely necessary.  I just don't know what *else* might be
   necessary.  It is almost certain that this sort of thing will be the primary
   problem when making other arches happy with this change (it was the only real
   thing I had to do with sparc, in patch 14, -fno-sparc-protecting the
   sigreturn handler, and just as with the pthread functions I don't really know
   why -- but it is clearly necessary.)

   It *is* clear why we have to -fno-stack-protect setjmp/sigjmp.c: the thing is
   *sibcalled* from assembler, and the assembler has pre-built a stack frame,
   complete with lack of canary, so setjmp/sigjmp.c had better not introduce
   one.  (Even in the absence of local variables, -fstack-protector-all will add
   a canary to the lone function in that file.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]