Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 05 Nov 2014 16:25:03 +0100
From: John Spencer <>
CC: Gregor Richards <>
Subject: fixing -fPIE + -fstack-protector-all

using -fPIE + -fstack-protector-all is currently broken for a number of 
architectures (most notably i386) in the default gcc setup (including 
the musl-cross patches), as it depends on a libssp_nonshared.a which 
provides __stack_chk_fail_local().

even when gcc's version is built from ssp-local.c and installed via
`make install-target-libssp`, gcc won't use it to link programs compiled 
with -fstack-protector[-all].
the reason is that (since we provide the rest of the ssp functionality 
in musl) we set gcc_cv_libc_provides_ssp=yes, which, contrary to our 
earlier expectations means: "libc provides ssp *and* ssp_nonshared":

(from gcc/gcc.c)
#define LINK_SSP_SPEC "%{fstack-protector:}"
#define LINK_SSP_SPEC 
"%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}"

so my conclusion is that in order to fix this issue cleanly and get musl 
support into upstream, we need to either (on the gcc side) define a new
gcc_cv_libc_provides_ssp_but_not_ssp_nonshared conditional and an 
install target that installs only libssp_nonshared but not libssp, and 
links only to libssp_nonshared if ssp was used, or somehow get that 
symbol (__stack_chk_fail_local()) into musl and linked to binaries in a 
way that doesn't require additional library flags on the linker command 

in the former case, the above snippet would look like

#define LINK_SSP_SPEC "%{fstack-protector:}"
#define LINK_SSP_SPEC 
#define LINK_SSP_SPEC 
"%{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}"


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.