From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] eglibc: defaults to SSP
Date: Fri, 23 Aug 2013 16:53:54 -0300 [thread overview]
Message-ID: <5217BDD2.1020806@zacarias.com.ar> (raw)
In-Reply-To: <20130823210931.4f2323fc@skate>
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.
next prev parent reply other threads:[~2013-08-23 19:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-27 14:32 [Buildroot] [PATCH] eglibc: defaults to SSP Gustavo Zacarias
2013-08-23 19:09 ` Thomas Petazzoni
2013-08-23 19:53 ` Gustavo Zacarias [this message]
2013-08-25 9:11 ` Thomas Petazzoni
2013-08-25 11:59 ` Gustavo Zacarias
2013-08-26 22:03 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5217BDD2.1020806@zacarias.com.ar \
--to=gustavo@zacarias.com.ar \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.