Patchwork eglibc: defaults to SSP

login
register
mail settings
Submitter Gustavo Zacarias
Date July 27, 2013, 2:32 p.m.
Message ID <1374935524-5259-1-git-send-email-gustavo@zacarias.com.ar>
Download mbox | patch
Permalink /patch/262455/
State Not Applicable
Headers show

Comments

Gustavo Zacarias - July 27, 2013, 2:32 p.m.
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(+)
Thomas Petazzoni - Aug. 23, 2013, 7:09 p.m.
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
Gustavo Zacarias - Aug. 23, 2013, 7:53 p.m.
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.
Thomas Petazzoni - Aug. 25, 2013, 9:11 a.m.
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
Gustavo Zacarias - Aug. 25, 2013, 11:59 a.m.
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.
Thomas Petazzoni - Aug. 26, 2013, 10:03 p.m.
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

Patch

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.