Recent ebuilds of sys-libs/glibc contain (e.g. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.35.ebuild?id=7d711f502a5cf86ae5e73c466d647fed33d4ae4a#n901): > case ${CTARGET} in > m68k*) > # setjmp() is not compatible with stack protection: > # https://sourceware.org/PR24202 > 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: https://sourceware.org/PR25680, bug #712356. > myconf+=( --enable-stack-protector=$(usex ssp strong no) ) > ;; > esac https://sourceware.org/PR24202 (affecting m68k) is fixed in >=sys-libs/glibc-2.33, so changes introduced in commit d74781e680bee416a48c648df1f8c6000da84e4d (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d74781e680bee416a48c648df1f8c6000da84e4d) probably can be reverted in >=sys-libs/glibc-2.33. https://sourceware.org/PR25680 (affecting all architectures) is fixed in >=sys-libs/glibc-2.34, so changes introduced in commit 551958422d949b8e43393b6c9c00a2ce7c4cc4c6 (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=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) )
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.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f58ea78c13b6078eade21a0de13e032e9ef49854 commit f58ea78c13b6078eade21a0de13e032e9ef49854 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-02-07 02:43:09 +0000 Commit: Sam James <sam@gentoo.org> 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. [0] https://sourceware.org/PR24202 [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=f294306ba1385b096f4e4cac9146a989f1e6d1c0 Bug: https://bugs.gentoo.org/832738 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.35.ebuild | 18 +++--------------- sys-libs/glibc/glibc-9999.ebuild | 24 ++++++------------------ 2 files changed, 9 insertions(+), 33 deletions(-)
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.
