[Bug build/7065] Support building glibc with -fstack-protector or -fstack-protector-all

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=7065

--- Comment #22 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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  a547a051a93361a9ec4edf283bcebea66481fca8 (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a547a051a93361a9ec4edf283bcebea66481fca8

commit a547a051a93361a9ec4edf283bcebea66481fca8
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:01:30 2016 +0100

    Enable -fstack-protector=* when requested by configure [BZ #7065]

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=299613826cccad6047f3bb4b9b2db97b9c899273

commit 299613826cccad6047f3bb4b9b2db97b9c899273
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:01:09 2016 +0100

    Do not stack-protect sigreturn stubs [BZ #7065]

    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.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=59780db53ac8f56a492ce2949159939865cefad6

commit 59780db53ac8f56a492ce2949159939865cefad6
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:01:00 2016 +0100

    Drop explicit stack-protection of pieces of the system [BZ #7065]

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8ac7f200cb4478e55b746c1b7739a2eb0dd58541

commit 8ac7f200cb4478e55b746c1b7739a2eb0dd58541
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:00:47 2016 +0100

    Link a non-libc-using test with -fno-stack-protector [BZ #7065]

    This test cannot reference __stack_chk_fail because it is not linked
    with libc at all.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a8c94a367800c222a068dfa56a696437bbf4b32d

commit a8c94a367800c222a068dfa56a696437bbf4b32d
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 15:58:22 2016 +0100

    PLT avoidance for __stack_chk_fail [BZ #7065]

    Add a hidden __stack_chk_fail_local alias to libc.so,
    and make sure that on targets which use __stack_chk_fail,
    this does not introduce a local PLT reference into libc.so.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=52c67c89daad240cfa76b39a4827ee6d4dada510

commit 52c67c89daad240cfa76b39a4827ee6d4dada510
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:00:22 2016 +0100

    Work even with compilers whcih enable -fstack-protector by default [BZ
#7065]

    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
    now.

    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.)

    When stack protection is disabled, explicitly pass -fno-stack-protector
    to everything, to stop a compiler hacked to enable it from inserting
    calls to __stack_chk_fail via the PLT in every object file.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ceaed0d1f8713b9de5bdeda919525c8fcd61d89a

commit ceaed0d1f8713b9de5bdeda919525c8fcd61d89a
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:00:13 2016 +0100

    Ignore __stack_chk_fail* in the rtld mapfile computation [BZ #7065]

    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.)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5abe578c24fce56130b9a44362907a83d076a06d

commit 5abe578c24fce56130b9a44362907a83d076a06d
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:00:03 2016 +0100

    Compile the dynamic linker without stack protection [BZ #7065]

    Also compile corresponding routines in the static libc.a with the same
    flag.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5ab1993e7799af49caacc86f1e3a4d335b2f3420

commit 5ab1993e7799af49caacc86f1e3a4d335b2f3420
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 15:59:47 2016 +0100

    Disable stack protector in early static initialization [BZ #7065]

    The startup code in csu/, and the brk and sbrk functions are
    needed very early in initialization of a statically-linked program,
    before the stack guard is initialized; TLS initialization also uses
    memcpy, which cannot overrun its own stack.  Mark all of these as
    -fno-stack-protector.

    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.)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=25becbb762c7a9aff36a389f2d63dcb5f7fecb7a

commit 25becbb762c7a9aff36a389f2d63dcb5f7fecb7a
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 15:59:32 2016 +0100

    Do not stack-protect ifunc resolvers [BZ #7065]

    When dynamically linking, ifunc resolvers are called before TLS is
    initialized, so they cannot be safely stack-protected.

    We avoid disabling stack-protection on large numbers of files by
    using __attribute__ ((__optimize__ ("-fno-stack-protector")))
    to turn it off just for the resolvers themselves.  (We provide
    the attribute even when statically linking, because we will later
    use it elsewhere too.)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8f26f41f502828d18ebe18adaf7e0e161b6005f9

commit 8f26f41f502828d18ebe18adaf7e0e161b6005f9
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 16:58:42 2016 +0100

    Initialize the stack guard earlier when linking statically [BZ #7065]

    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.

    In static appliations, __libc_setup_tls performs the TCB setup and TLS
    initialization, so this commit arranges for it to be called early and
    unconditionally.  The call (and the stack guard initialization) is
    before 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 __libc_setup_tls (though if stack-protection is
    enabled we still have to avoid calling functions that are not
    stack-protected at this stage).

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4d3eb50f579a017e8b68f1d28d7de2e026c1b20f

commit 4d3eb50f579a017e8b68f1d28d7de2e026c1b20f
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Dec 21 15:59:03 2016 +0100

    Configure support for --enable-stack-protector [BZ #7065]

    This adds =all and =strong, with obvious semantics, defaulting to off.

    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 also arrange to set the STACK_PROTECTOR_LEVEL #define to a value
    appropriate for the stack-protection level in use for each file in
    particular.

-----------------------------------------------------------------------

-- 
You are receiving this mail because:
You are on the CC list for the bug.