This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug build/7065] Support building glibc with -fstack-protector or -fstack-protector-all
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 26 Dec 2016 09:44:09 +0000
- Subject: [Bug build/7065] Support building glibc with -fstack-protector or -fstack-protector-all
- Auto-submitted: auto-generated
- References: <bug-7065-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=7065
--- Comment #23 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, master has been updated
via cecbc7967f0bcac718b6f8f8942b58403c0e917c (commit)
via 2e6c45c59bcd40f1ae8466cbd32f4d263ff45619 (commit)
via 1ad4ba28e9335c288687d1757bce3221c522f576 (commit)
via 7cbb738d218fad3bc91deebfd8ce5f3918592b84 (commit)
via 524a8ef2ad76af8ac049293d993a1856b0d888fb (commit)
via 66a704c43cfec810fea67a6959f2d1c94f4d594f (commit)
via bc174f20b83d19167ecac14ce0762eddbe47cc64 (commit)
via 995635f95b707488c23bba07be8016c9682d4045 (commit)
via 10c85e76c09716e744b4a41006718400b1eb2e84 (commit)
via de6591238b478bc86b8cf5af01a484114e399213 (commit)
via 003a27e8195470f470f4d9384ca70d4e9fc8bd1b (commit)
via 03baef1c9cfb396d76cae20a00aee657871e79c4 (commit)
from 81e0662e5f2c342ffa413826b7b100d56677b613 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cecbc7967f0bcac718b6f8f8942b58403c0e917c
commit cecbc7967f0bcac718b6f8f8942b58403c0e917c
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:09:10 2016 +0100
Enable -fstack-protector=* when requested by configure [BZ #7065]
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2e6c45c59bcd40f1ae8466cbd32f4d263ff45619
commit 2e6c45c59bcd40f1ae8466cbd32f4d263ff45619
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:09:06 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=1ad4ba28e9335c288687d1757bce3221c522f576
commit 1ad4ba28e9335c288687d1757bce3221c522f576
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:09:03 2016 +0100
Drop explicit stack-protection of pieces of the system [BZ #7065]
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7cbb738d218fad3bc91deebfd8ce5f3918592b84
commit 7cbb738d218fad3bc91deebfd8ce5f3918592b84
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:09:00 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=524a8ef2ad76af8ac049293d993a1856b0d888fb
commit 524a8ef2ad76af8ac049293d993a1856b0d888fb
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:57 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=66a704c43cfec810fea67a6959f2d1c94f4d594f
commit 66a704c43cfec810fea67a6959f2d1c94f4d594f
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:54 2016 +0100
Work even with compilers which 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=bc174f20b83d19167ecac14ce0762eddbe47cc64
commit bc174f20b83d19167ecac14ce0762eddbe47cc64
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:51 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=995635f95b707488c23bba07be8016c9682d4045
commit 995635f95b707488c23bba07be8016c9682d4045
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:48 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=10c85e76c09716e744b4a41006718400b1eb2e84
commit 10c85e76c09716e744b4a41006718400b1eb2e84
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:45 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=de6591238b478bc86b8cf5af01a484114e399213
commit de6591238b478bc86b8cf5af01a484114e399213
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:41 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=003a27e8195470f470f4d9384ca70d4e9fc8bd1b
commit 003a27e8195470f470f4d9384ca70d4e9fc8bd1b
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:34 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=03baef1c9cfb396d76cae20a00aee657871e79c4
commit 03baef1c9cfb396d76cae20a00aee657871e79c4
Author: Nick Alcock <nick.alcock@oracle.com>
Date: Mon Dec 26 10:08:18 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.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 149 +++++++++++++
INSTALL | 11 +
Makeconfig | 8 +-
NEWS | 4 +
aclocal.m4 | 6 +-
config.h.in | 10 +
config.make.in | 2 +
configure | 243 +++++++++++----------
configure.ac | 146 +++++++------
csu/Makefile | 4 +
csu/libc-start.c | 29 ++--
csu/libc-tls.c | 17 +-
debug/Makefile | 6 +
debug/stack_chk_fail.c | 2 +
elf/Makefile | 30 +++-
elf/ifuncdep2.c | 3 +
elf/ifuncmain6pie.c | 1 +
elf/ifuncmain7.c | 1 +
elf/ifuncmod1.c | 3 +
elf/ifuncmod5.c | 3 +
elf/rtld-Rules | 2 +
include/libc-symbols.h | 12 +-
login/Makefile | 1 -
manual/install.texi | 11 +
misc/Makefile | 7 +
nptl/nptl-init.c | 16 --
nscd/Makefile | 1 -
resolv/Makefile | 1 -
signal/Makefile | 2 +
string/Makefile | 4 +
sysdeps/generic/ifunc-sel.h | 2 +
sysdeps/generic/ldsodefs.h | 11 +
sysdeps/generic/symbol-hacks.h | 12 +
sysdeps/i386/Makefile | 2 +-
sysdeps/nacl/nacl_interface_query.c | 1 +
sysdeps/powerpc/ifunc-sel.h | 2 +
sysdeps/unix/make-syscalls.sh | 1 +
sysdeps/unix/sysv/linux/sparc/sparc32/sigaction.c | 8 +-
sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c | 4 +-
sysdeps/unix/sysv/linux/x86_64/x32/getcpu.c | 1 +
sysdeps/x86_64/ifuncmod8.c | 1 +
41 files changed, 539 insertions(+), 241 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.