Please enable GCC's -fstack-clash-protection for all profiles (not just hardened) in Gentoo by default.
So far we don have a way to only enable stack-clash by default.
USE=hardened (which is -DEXTRA_OPTIONS) controls both default of -z now and -fstack-clash-protection:
I'd like to see a few things first before enabling by default:
- split the patch in two: handle '-z now' and '-fstack-clash-protection' separately
- an equivalent of this patch upstreamed first in a way the default could be changed with a gcc's ./configure option (similar to --enable-default-ssp). That way we could report all found breakages upstream in some way.
- expose it as an use flag so users/targets could disable it for tests, code size or bare metal support.
Should not be hard to follow default-ssp:
It will probably have to be architecture-conditional.
As seen in GCC's gcc/toplev.c, using -fstack-clash-protection on some architectures would cause warning:
/* -fstack-clash-protection is not currently supported on targets
where the stack grows up. */
if (flag_stack_clash_protection && !STACK_GROWS_DOWNWARD)
warning_at (UNKNOWN_LOCATION, 0,
"%<-fstack-clash-protection%> is not supported on targets "
"where the stack grows from lower to higher addresses");
flag_stack_clash_protection = 0;
According to tc-stack-grows-down() function from toolchain-funcs.eclass, the only such architecture supported in Gentoo is hppa.
-fstack-clash-protection provides supposedly full protection against stack clash on:
arm64, ppc32, ppc64, rs6000, s390, x86, x86_64 (amd64)
-fstack-clash-protection provides partial protection against stack clash (re-using code of -fstack-check) on:
alpha, arm, ia64, mips, sparc, spu
-fstack-clash-protection is probably silently ignored on other architectures where stack grows down.
There might be architecture-specific bugs in implementation of -fstack-clash-protection. It will be probably useful to backport this fix for ICE on s390:
My suggestion is to introduce "default-stack-clash-protection" USE flag, force it in profiles/arch/base/package.use.force and mask it in profiles of architectures not supporting it (hppa, m68k, sh).
Gcc 9.X is closed for new options. A patch upstream will get in next version if it get accepted. Is okay for me to split the extra options patch.
Actually, I tried to check for default status of the flag and found out it's enabled by default on vanilla 8.2.0:
$ LANG=C gcc-8.2.0 -Q --help=common | fgrep stack-clash
Having reread the patch it enables -fstack-clash-protection along with USE=ssp, which is default on profiles that define it:
+/* Default value for flag_clash_protector when flag_clash_protector is
+ initialized to -1. */
+#define DEFAULT_FLAG_SCP 1
+#define DEFAULT_FLAG_SCP 0
Was it intentional?
The bug has been referenced in the following commit(s):
Author: Sergei Trofimovich <firstname.lastname@example.org>
AuthorDate: 2019-02-10 12:08:21 +0000
Commit: Sergei Trofimovich <email@example.com>
CommitDate: 2019-02-10 12:08:21 +0000
8.2.0: don't enable -fstack-clach-protection by default
In bug #675050 I noticed that -fstack-clash-protection is enabled
not just for hardened users but for USE=ssp users as well.
That was not an intention of the patch. The change enables
-fstack-clach-protection only for -DEXTRA_OPTIONS (hardened users).
See https://bugs.gentoo.org/675050 for longer-term plans to
enable -fstack-clach-protection for more users.
Signed-off-by: Sergei Trofimovich <firstname.lastname@example.org>
8.2.0/gentoo/55_all_extra-options.patch | 2 +-
8.2.0/gentoo/README.history | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)