| Message ID | 1374935524-5259-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Not Applicable |
| Headers | show |
Dear Gustavo Zacarias, On Sat, 27 Jul 2013 11:32:04 -0300, Gustavo Zacarias wrote: > And it doesn't seem to do anything when disabling it. > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> > --- > toolchain/toolchain-buildroot/Config.in.2 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/toolchain/toolchain-buildroot/Config.in.2 b/toolchain/toolchain-buildroot/Config.in.2 > index bf27e6b..f42d776 100644 > --- a/toolchain/toolchain-buildroot/Config.in.2 > +++ b/toolchain/toolchain-buildroot/Config.in.2 > @@ -19,6 +19,7 @@ comment "C++ support broken in uClibc with locale enabled with gcc 4.2" > > config BR2_TOOLCHAIN_BUILDROOT_USE_SSP > 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, Thomas
On 08/23/2013 04:09 PM, Thomas Petazzoni wrote: >> config BR2_TOOLCHAIN_BUILDROOT_USE_SSP >> 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, Hi. 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. Regards.
Dear Gustavo Zacarias, On Fri, 23 Aug 2013 16:53:54 -0300, Gustavo Zacarias wrote: > 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? Thomas
On 08/25/2013 06:11 AM, Thomas Petazzoni wrote: > 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? 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. Regards.
Dear Gustavo Zacarias, On Sun, 25 Aug 2013 08:59:41 -0300, Gustavo Zacarias wrote: > On 08/25/2013 06:11 AM, Thomas Petazzoni wrote: > > > 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. > > > > 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. Sure. > It's possible libssp might need to be handled (copied) for some external > toolchains depending on age too and how they were configured. Well, let's say we won't support this case for now :) However, this brings me to the same question for mudflap support. Mudflap is on one side a compiler feature and library, but also a compiler flag that you must use to enable mudflap on a particular binary. Should we have a "Enable mudflap usage" option in "Build options" that would build all binaries with -fmudflap, much like the "Enable SSP usage" would build all binaries with SSP usage? To be honest, I am not sure it makes a lot of sense to build *all* binaries with mudflap enabled. I believe one would generally only build a selection of its own libraries/applications with mudflap, mudflap being an analysis tool rather than a "corrective" tool. On the other hand, SSP is really a "corrective" feature in that it prevents some security holes from being exploited. For that reason, it makes sense to have a "Enable SSP usage" that passes -fstack-protector-all to all packages. Does this makes sense, or should Mudflap support also have the possibility of being enabled for all packages? Another question that comes to mind is that the "Enable SSP usage" option would be in "Build options", which sits *before* the "Toolchain" menu in menuconfig. However, the "Enable SSP usage" would only be visible if SSP is enabled at the toolchain level, so that might be confusing for the user. Thoughts? Best regards, Thomas
diff --git a/toolchain/toolchain-buildroot/Config.in.2 b/toolchain/toolchain-buildroot/Config.in.2 index bf27e6b..f42d776 100644 --- a/toolchain/toolchain-buildroot/Config.in.2 +++ b/toolchain/toolchain-buildroot/Config.in.2 @@ -19,6 +19,7 @@ comment "C++ support broken in uClibc with locale enabled with gcc 4.2" config BR2_TOOLCHAIN_BUILDROOT_USE_SSP bool "Enable stack protection support" + depends on !BR2_TOOLCHAIN_BUILDROOT_EGLIBC help Enable stack smashing protection support using GCCs -fstack-protector-all option.
And it doesn't seem to do anything when disabling it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- toolchain/toolchain-buildroot/Config.in.2 | 1 + 1 file changed, 1 insertion(+)