All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.