Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 832738

Summary: sys-libs/glibc: Revisit --enable-stack-protector value
Product: Gentoo Linux Reporter: Arfrever Frehtes Taifersar Arahesis <arfrever.fta>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: CONFIRMED ---    
Severity: normal CC: gentoo, m68k, om, sam
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: All   
See Also:
Package list:
Runtime testing required: ---

Description Arfrever Frehtes Taifersar Arahesis 2022-02-05 07:12:09 UTC
Recent ebuilds of sys-libs/glibc contain (e.g.
> 	case ${CTARGET} in
> 		m68k*)
> 			# setjmp() is not compatible with stack protection:
> 			#
> 			myconf+=( --enable-stack-protector=no )
> 			;;
> 		*)
> 			# Use '=strong' instead of '=all' to protect only functions
> 			# worth protecting from stack smashes.
> 			# '=all' is also known to have a problem in IFUNC resolution
> 			# tests:, bug #712356.
> 			myconf+=( --enable-stack-protector=$(usex ssp strong no) )
> 			;;
> 	esac (affecting m68k) is fixed in >=sys-libs/glibc-2.33, so changes introduced in commit d74781e680bee416a48c648df1f8c6000da84e4d ( probably can be reverted in >=sys-libs/glibc-2.33. (affecting all architectures) is fixed in >=sys-libs/glibc-2.34, so changes introduced in commit 551958422d949b8e43393b6c9c00a2ce7c4cc4c6 ( probably can be reverted in >=sys-libs/glibc-2.34.

If both assumptions are true, then this whole code can be simplified in >=sys-libs/glibc-2.34 into 1 line:
> 	myconf+=( --enable-stack-protector=$(usex ssp all no) )
Comment 1 James Le Cuirot gentoo-dev 2022-02-05 10:05:41 UTC
Oh cool, thanks for spotting that. I initially found the m68k bug, but I hadn't realised that slyfox had worked around it like this. I'll try changing it to "all" on m68k and see how it goes with some keywording/testing etc.
Comment 2 Larry the Git Cow gentoo-dev 2022-02-07 02:46:30 UTC
The bug has been referenced in the following commit(s):

commit f58ea78c13b6078eade21a0de13e032e9ef49854
Author:     Sam James <>
AuthorDate: 2022-02-07 02:43:09 +0000
Commit:     Sam James <>
CommitDate: 2022-02-07 02:45:29 +0000

    sys-libs/glibc: re-enable SSP for m68k; drop obsolete option in 2.35/9999
    - Re-enable SSP for m68k (it works now!) [0]
    - Drop no-op/obsolete/removed '--enable-stackguard-randomization' [1]
    But defer a decision on whether to make USE=ssp continue to
    mean -fstack-protector-strong or change to -fstack-protector-all now that
    test failure issues have veen fixed.
    Signed-off-by: Sam James <>

 sys-libs/glibc/glibc-2.35.ebuild | 18 +++---------------
 sys-libs/glibc/glibc-9999.ebuild | 24 ++++++------------------
 2 files changed, 9 insertions(+), 33 deletions(-)
Comment 3 Arfrever Frehtes Taifersar Arahesis 2022-02-07 04:07:52 UTC
GCC can be configured with -DDEFAULT_FLAG_SSP=2 to use -fstack-protector-all by default.
  -DDEFAULT_FLAG_SSP=1 makes -fstack-protector default
  -DDEFAULT_FLAG_SSP=2 makes -fstack-protector-all default
  -DDEFAULT_FLAG_SSP=3 makes -fstack-protector-strong default
  -DDEFAULT_FLAG_SSP=4 makes -fstack-protector-explicit default

Also users can add e.g. -fstack-protector-all explicitly to CFLAGS.

Currently used value can be queried from compiler:

$ gcc                            -E -P -dM - < /dev/null | grep SSP
#define __SSP_ALL__ 2
$ gcc -fstack-protector-all      -E -P -dM - < /dev/null | grep SSP
#define __SSP_ALL__ 2
$ gcc -fstack-protector-strong   -E -P -dM - < /dev/null | grep SSP
#define __SSP_STRONG__ 3
$ gcc -fstack-protector          -E -P -dM - < /dev/null | grep SSP
#define __SSP__ 1
$ gcc -fstack-protector-explicit -E -P -dM - < /dev/null | grep SSP
#define __SSP_EXPLICIT__ 4

If there is desire to use --enable-stack-protector=strong for these users who do not enable -fstack-protector-all, then ebuilds can query compiler ($(tc-getCC) ${CPPFLAGS} ${CFLAGS}) and use --enable-stack-protector=all only when __SSP_ALL__ is defined.