diff mbox

Bug 20662: checking whether x86_64-pc-linux-gnu-gcc implicitly enables -fstack-protector no (32bit gcc 6.2.0 pie and ssp enable)

Message ID 1784772.eOhSpX4WhJ@laptop1.gw.ume.nu
State New
Headers show

Commit Message

Magnus Granberg Oct. 20, 2016, 8:01 p.m. UTC 
When glibc get compile with gcc 6.2 that have been configured with
 --enable-default-pie and --enable-default-ssp. The check that check if the 
compiler use -fstack-protector as default fail on the 32bit part.

checking for libgd... no
checking for _FORTIFY_SOURCE predefine... yes
checking whether x86_64-pc-linux-gnu-gcc -m32 -Wl,-O1 -Wl,--as-needed 
implicitly enables -fstack-protector... no
checking whether the linker provides working __ehdr_start... yes

This patch make so we look for __stack_chk_fail_local in the check.
Tested on x86_64 multilib Gentoo

Changelog:

2016-10-20  Magnus Granberg  <zorry@gentoo.org>
		Denis Kaganovich  <mahatma@eu.by>

		* configure.ac:
		Add check for __stack_chk_fail_local in libc_cv_predef_stack_protector 	
		check.
		* configure: Regenerated.

---

Comments

Szabolcs Nagy Oct. 21, 2016, 8:58 a.m. UTC | #1 
On 20/10/16 21:01, Magnus Granberg wrote:
> When glibc get compile with gcc 6.2 that have been configured with

>  --enable-default-pie and --enable-default-ssp. The check that check if the 

> compiler use -fstack-protector as default fail on the 32bit part.

> 


i'm not against this patch, just note that any reasonable ssp
implementation would not make a call in case of failure, but
crash the application immediately, i hope gcc will have an
option in the future to do that, which means this check will
not work (the test would have to look for canary access, which
is target specific).
Magnus Granberg Oct. 22, 2016, 1:02 p.m. UTC | #2 
fredag 21 oktober 2016 kl. 09:58:08 CEST skrev  Szabolcs Nagy:
> On 20/10/16 21:01, Magnus Granberg wrote:

> > When glibc get compile with gcc 6.2 that have been configured with

> > 

> >  --enable-default-pie and --enable-default-ssp. The check that check if

> >  the

> > 

> > compiler use -fstack-protector as default fail on the 32bit part.

> 

> i'm not against this patch, just note that any reasonable ssp

> implementation would not make a call in case of failure, but

> crash the application immediately, i hope gcc will have an

> option in the future to do that, which means this check will

> not work (the test would have to look for canary access, which

> is target specific).

Thanks
Mike Frysinger Nov. 15, 2016, 7:37 p.m. UTC | #3 
thanks, i cleaned it up a bit and pushed it to master & 2.23 & 2.24
-mike
diff mbox

Patch

diff --git a/configure.ac b/configure.ac
index a64aeb9..de42b6b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1667,12 +1668,14 @@  echo >&AS_MESSAGE_LOG_FD "libc_undefs='$libc_undefs'"
 # symbols (resolved by the linker), so filter out unknown symbols.
 # This will fail to produce the correct result if the compiler
 # defaults to -fstack-protector but this produces an undefined symbol
-# other than __stack_chk_fail.  However, compilers like that have not
-# been encountered in practice.
-libc_undefs=`echo "$libc_undefs" | egrep '^(foobar|__stack_chk_fail)$'`
+# other than __stack_chk_fail or __stack_chk_fail_local. However,
+# compilers like that have not been encountered in practice.
+libc_undefs=`echo "$libc_undefs" | \
+  egrep '^(foobar|__stack_chk_fail|__stack_chk_fail_local)$'`
 case "$libc_undefs" in
 foobar) libc_cv_predef_stack_protector=no ;;
 '__stack_chk_fail
+foobar'|'__stack_chk_fail_local
 foobar') libc_cv_predef_stack_protector=yes ;;
 *) AC_MSG_ERROR([unexpected symbols in test: $libc_undefs]) ;;
 esac],