diff options
author | Nick Alcock <nick.alcock@oracle.com> | 2016-12-26 10:08:34 +0100 |
---|---|---|
committer | Florian Weimer <fweimer@redhat.com> | 2016-12-26 10:08:34 +0100 |
commit | 003a27e8195470f470f4d9384ca70d4e9fc8bd1b (patch) | |
tree | 9706d90e8c0806acaabde547fe8f1017329087b2 /configure | |
parent | 03baef1c9cfb396d76cae20a00aee657871e79c4 (diff) | |
download | glibc-003a27e8195470f470f4d9384ca70d4e9fc8bd1b.tar.gz glibc-003a27e8195470f470f4d9384ca70d4e9fc8bd1b.tar.xz glibc-003a27e8195470f470f4d9384ca70d4e9fc8bd1b.zip |
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).
Diffstat (limited to 'configure')
0 files changed, 0 insertions, 0 deletions