Bug 7065 - Support building glibc with -fstack-protector or -fstack-protector-all
Summary: Support building glibc with -fstack-protector or -fstack-protector-all
Alias: None
Product: glibc
Classification: Unclassified
Component: build (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2008-12-04 00:38 UTC by Nix
Modified: 2016-07-28 17:05 UTC (History)
10 users (show)

See Also:
Last reconfirmed:
fweimer: security-

stack protector support for glibc (7.71 KB, patch)
2008-12-04 00:55 UTC, Nix
Details | Diff
stack protector support against eglibc 2.13. (7.77 KB, patch)
2012-02-26 23:37 UTC, Nix
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nix 2008-12-04 00:38:31 UTC
Several distributions, including Gentoo, have patches which attempt to make 
glibc build when compiled with -fstack-protector. None of them that I have 
found actually work: at best, they make it crash instantly, because none of 
them suppress generation of stack guards around functions called before the 
guard is initialized (or even before ld-linux.so.2 has relocated itself).

For now I'd consider it more of a maintenance burden than it's worth to
isolate the parts of ld.so that are called before security_init(), so
I've just arranged to avoid using the stack-protector in ld.so, and
marked the few things not also in the dynamic loader which are used
during pre-guard-init static library initialization with
-fno-stack-protector. (An improvement might be to mark these with
-fno-stack-protector only when building the static library.)

I can't think of a way to isolate the functions in this set automatically, but 
if you get it wrong it's easy to tell because you get an instant coredump, so 
it's easy to prevent the set of -fno-stack-protectored functions from 
bitrotting, manually maintained though it must be.)

You can still use -fstack-protector-all in all the rest of glibc, which
is an order of magnitude more code than ld.so and includes really hairy
stuff like malloc() and lots of functions that themselves call
string-manipulation functions, so I'd say this is a pretty good

Some of the module tests need adjustment: they don't link against
libc, so must specify -fno-stack-protector; the same is true of some of the 
configury, taking care not to specify that unless GCC is actually capable of 
accepting -fstack-protector. (We specify -lssp and leave the stack protector on 
where possible in configure tests.)

Results of tests and patch against glibc 2.9 following shortly.
Comment 1 Ulrich Drepper 2008-12-04 00:44:36 UTC
Never going to happen.
Comment 2 Nix 2008-12-04 00:53:50 UTC
test environment: kernel+headers, glibc 2.8, GCC 4.3.3 20081121 
(prerelease), binutils 2.19.

config flags (my standard set for this machine):

/usr/packages/glibc/2.9/configure --prefix=/usr --enable-shared \
    --enable-profile --disable-bounded --enable-bind-now        \
    --enable-add-ons=nptl,libidn --enable-kernel=2.6.25         \
    --enable-check-abi=warn --enable-omitfp                     \
    --enable-stackguard-randomization TIMEOUTFACTOR=5

Below, PASS means 'baseline test failures only'. (I also compared
configure output to verify that -fstack-protector addition did not
change the results of any configure tests, and verified that the
appropriate -fstack-protector actually appeared in gcc commandlines at
the appropriate times.)

baseline:                              PASS, by definition
patch applied, no flags specified:     PASS
-fstack-protector in CFLAGS:           PASS
-fstack-protector-all in CFLAGS:       one failure due to #7066, buffer overrun
--without-stack-protector:             PASS
--with-stack-protector:                PASS
--with-stack-protector=all:            one failure due to #7066, buffer overrun

Test failures for baseline (unpatched):


testing long double (inline functions)
Failure: Test: expm1 (1) == M_El - 1.0
 is:          1.71828182845904523532e+00   0xd.bf0a8b14576953500000p-3
 should be:   1.71828182845904523543e+00   0xd.bf0a8b14576953600000p-3
 difference:  1.08420217248550443401e-19   0x8.00000000000000000000p-66
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `expm1'
 is      : 1 ulp
 accepted: 0 ulp

Test suite completed:
  3618 test cases plus 3005 tests for exception flags executed.
  2 errors occurred.


--- ../scripts/data/localplt-i386-linux-gnu.data        2006-01-11 
21:06:19.000000000 +0000
+++ -   2008-11-30 20:52:09.962033876 +0000
@@ -1,4 +1,5 @@
 libc.so: _Unwind_Find_FDE
+libc.so: __bzero
 libc.so: calloc
 libc.so: free
 libc.so: malloc

(This looks like something missing from localplt-i386-linux-gnu.data to
me, not a bug.)

(Holes in test coverage: not tested with a GCC too old to support
-fstack-protector. Static testing not performed: see #7064.)
Comment 3 Nix 2008-12-04 00:55:44 UTC
Created attachment 3087 [details]
stack protector support for glibc

This is posted at the request of Carlos O'Donell. TBH I don't care if it
doesn't go upstream, although given that it's already found a buffer overrun in
glibc I'd find that surprising. I'm more interested in distros picking it up.

(And 'never going to happen' is a peculiar statement. It has 'happened'. The
patch *exists*.)
Comment 4 Ryan S. Arnold 2008-12-10 17:09:10 UTC

A failure in elf/check-localplt.out as indicated by a new symbol in
scripts/data/localplt-i386-linux-gnu.data means that libc proper is invoking the
new symbol via the plt when in-fact it should be making a direct invocation to a
libc internal symbol.  There are very few conditions under which this is allowed
(notably those cases where we allow libc functionality to be overridden).

I've looked through the code and it appears that the sunrpc code is the only
relevant code which uses __bzero.  I don't think there's an internal hidden
version of the symbol.  So these calls to __bzero probably shouldn't be there. 
Instead, they should use memset.  Or perhaps that patch which you're using uses

In order to verify, one can look at the symbol table:

objdump -DR libc.so > libc.dis

Search libc.dis for:


You should see a plt call stub, e.g.

00016198 <__bzero@plt>:
   16198:       ff a3 0c 00 00 00       jmp    *0xc(%ebx)
   1619e:       68 00 00 00 00          push   $0x0
   161a3:       e9 e0 ff ff ff          jmp    16188 <h_errno+0x16168>

Now search for: "call   16198"

call   16198 <__bzero@plt>

This should bring you to the disassembly of the function which invoked __bzero
via the PLT.  You can then go into the C source file and replace this with a
memset.  Do this for all calls to the address for __bzero.
Comment 5 Ryan S. Arnold 2008-12-10 18:51:38 UTC
Here's a more thorough write-up of the same thing I just posted:


Invocation of __bzero() by the sunrpc code is acceptable since that code is in a
different library than libc.so so access via the PLT is expected.
Comment 6 Nix 2008-12-13 19:02:50 UTC
Nice description, Ryan :)

A lot of the sunrpc code *does* land in libc (all the client code). Notably, 
bindresvport(), clnt_create(), clnt_broadcast(), universal() (called from 
registerrpc() via a callback from svc_register()), svctcp_create(), 
svcudp_bufcreate(), and key_gendes(), _des_crypt() (obviously used for 
DES-encrypted SunRPC), all explicitly call __bzero() and land in libc.

Almost certainly these would use memset() were the SunRPC code not ancient 
Sun-derived gunge with a 1986 copyright date...
Comment 7 Attila Tóth 2008-12-14 11:32:10 UTC
Keep it going, guys.

To Ulrich Drepper:
How do you mean: "Never going to happen."?!

I always keen on people ignoring security measures.

Comment 8 Robert Connolly 2009-06-04 22:25:35 UTC
I've been using a compromise. Glibc's programs can be compiled 
with -fstack-protector-all, or whatever other options you may want 
(-D_FORTIFY_SOURCE=2, -fPIE, etc), but not the libraries. I use the configparms 
file and set build-programs=no to build the libraries 
without -fstack-protector, then remove build-programs=no and add 'CFLAGS 
+= -fstack-protector-all' to configparms. No patches needed, test suites pass 
(remove -fstack-protector during the test suite), no crashes.
Comment 9 Nix 2012-02-26 23:37:48 UTC
Created attachment 6248 [details]
stack protector support against eglibc 2.13.

This is the most recent version of this patch, against eglibc 2.13 (because that happens to be the version I'm using now, as I track Debian's glibc). It has needed no significant revisions for years, though the recent csu changes in upstream glibc may necessitate some small revisions.

(The ChangeLog is out of date: I haven't regenerated it since 2008.)
Comment 10 Andreas Jaeger 2012-04-21 12:55:37 UTC
Your change contains two different changes:
* Supporting stack-protector
* A different implementation of chk_fail function

For addition to glibc, I would only look at the stack-protector support. I suggest you continue discussing this on the libc-alpha list.
Comment 11 Jackie Rosen 2014-02-16 19:20:15 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
Comment 12 Nick Alcock 2016-02-17 10:19:41 UTC
(In reply to Andreas Jaeger from comment #10)
> Your change contains two different changes:
> * Supporting stack-protector
> * A different implementation of chk_fail function
> For addition to glibc, I would only look at the stack-protector support. I
> suggest you continue discussing this on the libc-alpha list.

It's terribly late (I frankly forgot this bug existed) but I'm about to reanimate this one. (I suspect it protects me from CVE-2015-7545 and it seems unfair to keep it to myself like this.)

However, splitting the different changes apart is rather difficult: the stack-protector changes actually depend on the different stack_chk_fail, because the existing __stack_chk_fail() -> __fortify_fail() -> __libc_message() path ends up calling down to libio and the like, and if you're to use those for __stack_chk_fail() all those routines cannot themselves be compiled with stack-protection. The gentoo-derived routine I replaced it with uses none of that, and is standalone.

Anyway -- that's just one of several possible problems with this patch! I'll reanimate the patch against trunk and then bring it up on the list (and my apologies for putting it off for so long).
Comment 13 Nick Alcock 2016-02-17 10:22:16 UTC
(In reply to Nick Alcock from comment #12)
> It's terribly late (I frankly forgot this bug existed) but I'm about to
> reanimate this one. (I suspect it protects me from CVE-2015-7545 and it
> seems unfair to keep it to myself like this.)

Damn typos. CVE-2015-7547 of course. CVEs should have a check digit, I make this sort of typo way too often.
Comment 14 Attila Tóth 2016-02-19 10:26:43 UTC
(In reply to Nick Alcock from comment #12)
> (In reply to Andreas Jaeger from comment #10)
> > Your change contains two different changes:
> > * Supporting stack-protector
> > * A different implementation of chk_fail function
> > 
> > For addition to glibc, I would only look at the stack-protector support. I
> > suggest you continue discussing this on the libc-alpha list.
> Anyway -- that's just one of several possible problems with this patch! I'll
> reanimate the patch against trunk and then bring it up on the list (and my
> apologies for putting it off for so long).

Happy to hear about it. Please share your stuff! Thx: Dw.
Comment 15 Nick Alcock 2016-02-20 10:27:26 UTC
Initial patch series (against trunk as of a couple of days ago) posted for review, complete with rough bits, "I don't understand this" bits, bits I posted specifically so they could be rejected and no changelog. But it works, and has no test failures. :)
Comment 16 Magnus Granberg 2016-02-20 11:57:27 UTC
(In reply to Nick Alcock from comment #15)
> Initial patch series (against trunk as of a couple of days ago) posted for
> review, complete with rough bits, "I don't understand this" bits, bits I
> posted specifically so they could be rejected and no changelog. But it
> works, and has no test failures. :)

The stack_chk_fail.c have been updated on >= glibc-2.20 on Gentoo
On Gcc 6.0 it is a default configure option to turn on stack-protector-strong.
Keep up the work
Comment 17 Nick Alcock 2016-02-20 12:02:26 UTC
Yeah, that looks nice! though with its replacing all the chk functions it's even more clearly a separate thing (though still a prerequisite for my patch).
Comment 18 Nick Alcock 2016-03-08 14:14:08 UTC
Aside: just posted v5. No new failures remain on {x86,sparc}*-pc-linux-gnu or armv7l-unknown-linux-gnueabihf, and the entire package saving only ifunc resolvers, ld.so, a tiny bit of BSD signal handling, and early static library startup (unfortunately including brk() and sbrk()) is protected.
Comment 19 Nick Alcock 2016-03-08 14:15:07 UTC
Oh, and we no longer need to replace __stack_chk_fail etc as of a few patches ago (figured out the true root cause and fixed it properly).
Comment 20 cvs-commit@gcc.gnu.org 2016-07-28 17:05:56 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, fw/stack-protector has been created
        at  82f2eb623ce1d9bd0a4d2c45d9d47688e71ed383 (commit)

- Log -----------------------------------------------------------------

commit 82f2eb623ce1d9bd0a4d2c45d9d47688e71ed383
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:16 2016 +0100

    Enable -fstack-protector=* when requested by configure.
    This finally turns on all the machinery added in previous commits.
    v3: Wrap long lines.
    v5: Shuffle to the end.
    	* Makeconfig (+stack-protector): New variable.
    	(+cflags): Use it.


commit 11533a025509becc37503eab765e8e769e882283
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:15 2016 +0100

    Do not stack-protect sigreturn stubs.
    These are called from the kernel with the stack at a carefully-
    chosen location so that the stack frame can be restored: they must not
    move the stack pointer lest garbage be restored into the registers.
    We explicitly inhibit protection for SPARC and for signal/sigreturn.c:
    other arches either define their sigreturn stubs in .S files, or (i386,
    x86_64, mips) use macros expanding to top-level asm blocks and explicit
    labels in the text section to mock up a "function" without telling the
    compiler that one is there at all.
    v2: New.
    v3: Use $(no-stack-protector).
    v4: Use inhibit_stack_protector.
    v7: Add sigreturn.c.
    	* signal/Makefile (CFLAGS-sigreturn.c): Use
    	* sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c:
    	(__rt_sigreturn_stub): Use inhibit_stack_protector.
    	* sysdeps/unix/sysv/linux/sparc/sparc32/sigaction.c
    	(__rt_sigreturn_stub): Likewise.
    	(__sigreturn_stub): Likewise.


commit 14b3c413f1b1dd1bfc0bae45fc042a4de56b85af
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:14 2016 +0100

    Drop explicit stack-protection of pieces of the system.
    This is probably a bad idea: maybe we want to stack-protect some parts
    of the system even when ! --enable-stack-protector.  I can easily adjust
    the patch to do that (though it'll mean introducing a new variable
    analogous to $(stack-protector) but not controlled by the configure
    But if we wanted to value consistency over security, and use the same
    stack-protection configure flag to control everything, this is how we'd
    do it!
    ("Always include at least one patch with something obviously wrong with
    	* login/Makefile (pt_chown-cflags): Remove.
    	* nscd/Makefile (CFLAGS-nscd): Likewise.
    	* resolv/Makefile (CFLAGS-libresolv): Likewise.


commit 72bb1d426913236e2059e0001afcd75782ef8ff6
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:13 2016 +0100

    Link various tests with -fno-stack-protector.
    These tests do not link with libc, so cannot see __stack_chk_fail().
    v3: Use $(no-stack-protector).
    	* elf/Makefile (CFLAGS-filtmod1.c): Use $(no-stack-protector) for
    	non-libc-linking testcase.
    	(CFLAGS-filtmod2.c): Likewise.
    	* stdlib/Makefile (CFLAGS-tst-putenvmod.c): Likewise.
    	* sysdeps/x86_64/Makefile (CFLAGS-tst-quad1pie.c): Likewise.
    	(CFLAGS-tst-quad2pie.c): Likewise.


commit f738b8f9e2c63772979e26e491ecf055bff28c50
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Tue Jun 7 12:06:12 2016 +0100

    De-PLTize __stack_chk_fail internal calls within libc.so.
    We use the same assembler-macro trick we use to de-PLTize
    compiler-generated libcalls to memcpy and memset to redirect
    __stack_chk_fail to __stack_chk_fail_local.
    v5: New.
    v6: Only do it within the shared library: with __stack_chk_fail_local
        in libc_pic.a now we don't need to worry about calls from inside
        other routines in libc_nonshared.a any more.
    	* sysdeps/generic/symbol-hacks.h (__stack_chk_fail): Add internal


commit 4f2b01de3ab88daefdc239a3c25640153b88283d
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:11 2016 +0100

    Add stack_chk_fail_local to libc.so.
    This is required by the next commit, which routes all
    __stack_chk_fail() calls in libc.so via this function to avoid
    the PLT.  It has be duplicated in libc.so and libc_nonshared.a
    because its entire reason for existence is to be hidden and avoid
    the PLT, so the copy in libc.so is not visible from elsewhere.
    Also stop all the variants of __stack_chk_fail from being stack-
    protected: this makes no sense and risks recursion.
    v5: Better explanation.  Add no-stack-protection of
        __stack_chk_fail_local etc.
    v6: Rework as suggested by Andreas: make a shared-only version of
        stack_chk_fail_local.c rather than linking libc_nonshared into
    	* debug/libc-stack_chk_fail_local.c: New file.
    	* debug/Makefile (routines): Add it.
    	(shared-only-routines): Likewise.
    	(CFLAGS-stack_chk_fail.c): Use $(no-stack-protector).
    	(CFLAGS-stack_chk_fail_local.c): Likewise.
    	(CFLAGS-libc-stack_chk_fail_local.c): Likewise.


commit 085d48cdc5494e642cc7016649a75ab200a03781
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:10 2016 +0100

    Work even with compilers hacked to enable -fstack-protector by default.
    With all the machinery we just added, we can easily arrange to work even
    when the compiler passes in -fstack-protector automatically: all the
    necessary bits of glibc are always compiled with -fno-stack-protector
    So tear out the check in configure, and add appropriate calls to
    -fno-stack-protector in tests that need them (largely those that use
    -nostdlib), since we don't yet have a __stack_chk_fail() that those
    tests can rely upon.  (GCC often provides one, but we cannot rely on
    this, especially not when bootstrapping.)
    v2: No longer pass in -lssp to anything.
    v5: Remove accidentally duplicated $(no_ssp)s.
    v6: Small revisions following Mike Frysinger's review.
    	* configure.ac: Add check for unsupported stack-protection level.
    	(libc_cv_predef_stack_protector): Remove.
    	(no_ssp): New variable.
    	(libc_cv_ld_gnu_indirect_function): Use it.
    	(libc_cv_asm_set_directive): Likewise.
    	(libc_cv_protected_data): Likewise.
    	(libc_cv_z_combreloc): Likewise.
    	(libc_cv_hashstyle): Likewise.
    	(libc_cv_has_glob_dat): Likewise.
    	(libc_cv_output_format): Likewise.
    	(libc_cv_ehdr_start): Likewise.
    	* aclocal.m4 (LIBC_TRY_LINK_STATIC): Likewise.
    	(LIBC_LINKER_FEATURE): Likewise.


commit 10bb23d6cd48055ba4974119bc1cf87f4d8063e5
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:09 2016 +0100

    Prevent the rtld mapfile computation from dragging in __stack_chk_fail*.
    The previous commit prevented rtld itself from being built with
    -fstack-protector, but this is not quite enough.  We identify which
    objects belong in rtld via a test link and analysis of the resulting
    mapfile.  That link is necessarily done against objects that are
    stack-protected, so drags in __stack_chk_fail_local, __stack_chk_fail,
    and all the libc and libio code they use.
    To stop this happening, use --defsym in the test librtld.map-production
    link to force the linker to predefine these two symbols (to 0, but it
    could be to anything).  (In a real link, this would of course be
    catastrophic, but these object files are never used for anything else.)
    v2: New.
    v6: Dummy out stack_chk_fail_local too.
    	* elf/Makefile (dummy-stack-chk-fail): New.
    	($(objpfx)librtld.map): Use it.


commit 0718bc3e5680502076efaba7fe3000d8d896c52f
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:08 2016 +0100

    Compile the entire dynamic linker with -fno-stack-protector.
    Also compile corresponding routines in the static libc.a with the same
    v3: Use $(no-stack-protector).
        Introduce $(elide-stack-protector) and use it to reduce redundancy.
        Bring all the elisions together textually.
    	* elf/Makefile (elide-stack-protector): New.
    	(CFLAGS-.os): Use it, eliding $(all-rtld-routines).
    	(CFLAGS-.oX): Likewise, eliding $(elide-routines.os).
    	(rtld-CFLAGS): Likewise.


commit dcb6b662b71117834db8732bd46649557f554a58
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:06 2016 +0100

    Mark all machinery needed in early static-link init as -fno-stack-protector.
    The startup code in csu/, brk() and sbrk(), and the
    __pthread_initialize_tcb_internal() function we just introduced are
    needed very early in initialization of a statically-linked program,
    before the stack guard is initialized.  Mark all of these as
    We also finally introduce @libc_cv_ssp@ and @no_stack_protector@, both
    substituted by the configury changes made earlier, to detect the case
    when -fno-stack-protector is supported by the compiler, and
    unconditionally pass it in when this is the case, whether or not
    --enable-stack-protector is passed to configure.  (This means that
    it'll even work when the compiler's been hacked to pass
    -fstack-protector by default, unless the hackage is so broken that
    it does so in a way that is impossible to override.)
    (At one point we marked __libc_fatal() as non-stack-protected too,
    but this was pointless: all it did was call other routines which *are*
    stack-protected.  The earliest __libc_fatal() call is in the
    DL_SYSDEP_OSCHECK hook on some platforms, when statically linking:
    this is fine, since it is after TLS and stack-canary initialization.
    I have tested invocation of programs statically and dynamically
    linked against this glibc on older kernels on x86 and ARM, and they
    still "work", i.e. fail with the appropriate message.)
    v2: No longer mark memcpy() as -fno-stack-protector.
    v3: Use $(no-stack-protector).
    v4: Use inhibit_stack_protector rather than de-protecting all of nptl-init.c.
    v5: Don't stack-protect brk() and sbrk() in the shared library.
    v7: Add comment in misc/Makefile.  Commit message tweak.
    	* config.make.in (have-ssp): New.
    	(no-stack-protector): New.
    	* csu/Makefile (CFLAGS-.o): Use it.
    	(CFLAGS-.og): Likewise.
    	(CFLAGS-.op): Likewise.
    	(CFLAGS-.os): Likewise.
    	* misc/Makefile (CFLAGS-sbrk.o): Likewise.
    	(CFLAGS-sbrk.op): Likewise.
    	(CFLAGS-sbrk.og): Likewise.
    	(CFLAGS-brk.o): Likewise.
    	(CFLAGS-brk.op): Likewise.
    	(CFLAGS-brk.og): Likewise.
    	* nptl/nptl-init.c [!SHARED] (__pthread_initialize_tcb_internal):


commit d23b1cd0cf47428831e451eb7fda5434982b0675
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Jul 4 12:25:57 2016 +0200

    Define inhibit_stack_protector


commit 1a410af4d0c0b57ca0eff9546cf18539ebfce8af
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:04 2016 +0100

    Initialize the stack guard earlier when linking statically.
    The address of the stack canary is stored in a per-thread variable,
    which means that we must ensure that the TLS area is intialized before
    calling any -fstack-protector'ed functions.  For dynamically linked
    applications, we ensure this (in a later patch) by disabling
    -fstack-protector for the whole dynamic linker, but for static
    applications the AT_ENTRY address is called directly by the kernel, so
    we must deal with the problem differently.
    So split out the part of pthread initialization that sets up the TCB
    (and, more generally, the TLS area) into a separate function (twice --
    there is one implementation in libpthread.a, and another outside it for
    programs that do not link with libpthread), then call it at
    initialization time.  Call that, and move the stack guard initialization
    above the DL_SYSDEP_OSCHECK hook, which if set will probably call
    functions which are stack-protected (it does on Linux and NaCL too).
    We also move apply_irel() up, so that we can still safely call functions
    that require ifuncs while in __pthread_initialize_tcb_internal()
    (though if stack-protection is enabled we still have to avoid calling
    functions that are not stack-protected at this stage).
    v2: describe why we don't move apply_irel() up, and the consequences.
    v6: We can safely move apply_irel() up now.
    	* nptl/nptl-init.c (__pthread_initialize_tcb_internal): New
    	function, split out from...
    	(__pthread_initialize_minimal_internal): ... here.
    	* csu/libc-start.c (LIBC_START_MAIN): Call it.  Move stack canary
    	and apply_irel() initialization up.


commit c090aec57a599df633c4ee175dab96c3642f7c84
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jun 7 12:06:03 2016 +0100

    Configury support for --enable-stack-protector.
    This adds =all and =strong, with obvious semantics, and with a rather
    arbitrarily-chosen default off, which we might well want to change to
    something stronger once this patch has been tested by people other than
    We don't validate the value of the option yet: that's in a later patch.
    Nor do we use it for anything at this stage.
    We differentiate between 'the compiler understands -fstack-protector'
    and 'the user wanted -fstack-protector' so that we can pass
    -fno-stack-protector in appropriate places even if the user didn't want
    to turn on -fstack-protector for other parts.  (This helps us overcome
    another existing limitation, that glibc doesn't work with GCCs hacked
    to pass in -fstack-protector by default.)
    We might want to add another configuration option to turn on
    -fstack-protector for nscd and other network-facing operations by
    default, but for now I've stuck with one option to control everything.
    v2: documentation in install.texi; better description of the option.
        INSTALL regenerated.
    v3: Substitute in no_stack_protector.
    v6: Small quoting/spacing revisions following Mike Frysinger's review.
    v7: Quoting changes. Report --enable-stack-protector argument values
        on error.
    	[BZ #7065]
    	* configure.ac (libc_cv_ssp): Move up.
    	(libc_cv_ssp_strong): Likewise.
    	(libc_cv_ssp_all): New.
    	(stack_protector): Augment, adding -fstack-protector-all.
    	(no_stack_protector): New.
    	(AC_ARG_ENABLE(stack-protector)): New configure flag.
    	* manual/install.texi (--enable-stack-protector): Document it.
    	* config.h.in (STACK_PROTECTOR_LEVEL): New macro.
    	* INSTALL: Regenerate.