eglibc: defaults to SSP

And it doesn't seem to do anything when disabling it.

Signed-off-by Gustavo Zacarias <[email protected]>

---
 toolchain/toolchain-buildroot/Config.in.2 | 1 +
 1 file changed, 1 insertion(+)

toolchain/toolchain-buildroot/Config.in.2 +0 -0

index bf27e6b..f42d776 100644

toolchain/toolchain-buildroot/Config.in.2 comment "C++ support broken in uClibc with locale enabled with gcc 4.2" · line 25

Quoted 6 lines

config BR2_TOOLCHAIN_BUILDROOT_USE_SSP

toolchain/toolchain-buildroot/Config.in.2 +1 -0

 	bool "Enable stack protection support"
+	depends on !BR2_TOOLCHAIN_BUILDROOT_EGLIBC
 	help
 	  Enable stack smashing protection support using GCCs
 	  -fstack-protector-all option.

I'm jumping on this as I was looking in a bit more details at the SSP support. It seems that GCC itself has a libssp library, and some external toolchains (such as the Linaro one) has a libssp.so that is apparently provided by GCC, while usually the SSP symbols (__stack_chk_fail and al.) are provided by the C library.

Currently BR2_TOOLCHAIN_BUILDROOT_USE_SSP is a toolchain option of the Buildroot internal backend. But what if I want to use SSP support with an external toolchain? You made this symbol depend
on !BR2_TOOLCHAIN_BUILDROOT_EGLIBC, but BR2_TOOLCHAIN_BUILDROOT_USE_SSP is also used to add the -fstack-protector-all to the CFLAGS when compiling all packages, which is also useful when eglibc is used, no?

Thanks for your insights,

This patch was never applied since it's wrong (hence i ditched it from patchwork).
We need to build with -fstack-protector-all even for eglibc. Eglibc (at least the version we ship for internal toolchain) defaults to support/build stack protection support on so the option is valid. We don't have glibc support (yet - pending on your patches) but AFAIK for modern-ish versions of glibc that's also the case.
For external toolchains, well, there's varying support i take it depeding on toolchain component versions.

libssp wouldn't normally be necessary for modern toolchains except for MAYBE compatibility reasons which i don't think we should care about (old blobby apps linked against libssp) or if the toolchain has old components so libssp shouldn't necessarily be copied, at least not as a default.
Doing the nasty trick with sourcery 2013.05 ARM (qemu_arm_versatile) with BR2_TARGET_OPTIMIZATION="-fstack-protector-all" works fine for example without the need for tweaks.

Ok, so if we try to summarize this:

* The option to enable SSP should be in "Build options" and not in the "Toolchain" menu, because what it mainly does is adjust the CFLAGS/CXXFLAGS for all packages.

* In the case of the internal toolchain backend, it would make sure that the SSP support in the C library in enabled. I.e, nothing for eglibc/glibc, and enable SSP for uClibc.

* In the case of the external toolchain backend, we would need to have an option like "Toolchain supports SSP?" that the user must fill in. But this would mean the "Use SSP" option in "Build options" would have to depend on the "Toolchain supports SSP?" option.

Something like that?

Quoted 15 lines · Thomas Petazzoni

Ok, so if we try to summarize this:

* The option to enable SSP should be in "Build options" and not in the "Toolchain" menu, because what it mainly does is adjust the CFLAGS/CXXFLAGS for all packages.

* In the case of the internal toolchain backend, it would make surey, that the SSP support in the C library in enabled. I.e, nothing for eglibc/glibc, and enable SSP for uClibc.

* In the case of the external toolchain backend, we would need to have an option like "Toolchain supports SSP?" that the user must fill in. But this would mean the "Use SSP" option in "Build options" would have to depend on the "Toolchain supports SSP?" option.

Quoted 1 line

Something like that?

Yes, i'd add for the last point "if custom external toolchain" because we can determine if the predefined toolchain has ssp when it's bumped/added with an internal knob.

It's possible libssp might need to be handled (copied) for some external toolchains depending on age too and how they were configured.