This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
--enable-stack-protector for glibc, v5
- From: Nix <nix at esperi dot org dot uk>
- To: libc-alpha at sourceware dot org
- Date: Tue, 8 Mar 2016 13:50:46 +0000
- Subject: --enable-stack-protector for glibc, v5
- Authentication-results: sourceware.org; auth=none
This is version 5 of the stack-protected glibc patch, incorporating all review
comments to date (unless I missed some), and finally clearing up the long-
standing mystery surrounding __pthread_mutex_unlock_usercnt() et al.
It's not rebased and is still against glibc head as of a few weeks ago,
a5df3210a641c17.
Tested with these flag combinations on {i686,x86_64)-pc-linux-gnu:
--enable-omitfp --enable-stack-protector=all
--enable-stack-protector
--enable-stack-protector=strong
--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
--disable-stack-protector
--enable-stack-protector=no
Tested with with these flag combinations on sparc{32,64}-pc-linux-gnu:
--enable-stack-protector
--enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=strong
--enable-stackguard-randomization --enable-stack-protector=all
--disable-stack-protector
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
--enable-stackguard-randomization --enable-stack-protector=all --enable-omitfp
--disable-stack-protector
No failures are observed that are not also observed on an unpatched glibc with
the same flag combinations. (There is one intermittent failure on arm: a
segfault from nptl/tst-cancelx17. However, it intermittently fails for me on the
unpatched baseline too, so I'm not making it any worse!)
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. (Patch 11 is
in Adhemerval's name, but obviously there's no assignment problem there either.)
The only remaining question I really have is what to do instead of patch 14,
which I really do expect to be rejected. Another configure argument to set the
stack-protection level of externally-facing components, perhaps, or simply a
wiring-in that if --enable-stack-protector is not passed, that -fstack-protector
is passed in for these external components anyway? What I do think is that the
level set via --enable-stack-protector should be a minimum: that libresolv, nscd
et al should never be protected *less* than libc.so and the rest are. Patch 14
was a nice simple way to do that, but it is probably *too* simple...
Overview of changes in this posting:
- Do not call __stack_chk_fail through the PLT for calls within libc itself,
and calls within libc_nonshared.a as well.
- Do not build __stack_chk_fail or __stack_chk_fail_local with stack-protection
to avoid the (very unlikely) possibility of recursion.
- Fix the comment describing of inhibit_stack_protector, which was
incomprehensible.
- Solve the great __pthread_mutex_unlock_usercnt() mystery: see patch N in the
series. Stack protection wasn't breaking anything, it was just legitimately
clobbering a register it was allowed to clobber, and the i386 assembly
implementation of pthread_cond_wait() et al were assuming it was not
clobbered across calls. All of the non-assembly parts of threading other
than ifunc resolvers and a one-line initialization function in nptl-init.c
are now stack-protected.
- Stack-protect brk() and sbrk() in the shared library: they only need to be
unprotected in the three varieties of static libc, where they are used in
early init.
- Reshuffle the series so that it is always compilable (I think). (This was
once true, but commits had crept in after the commit that wired up the
--enable-stack-protector configure flag into a -fstack-protector compiler
flag.)
- Changelogs for everything.
Remaining mysteries:
- None!