From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] eglibc: defaults to SSP
Date: Tue, 27 Aug 2013 00:03:46 +0200 [thread overview]
Message-ID: <20130827000346.6abde816@skate> (raw)
In-Reply-To: <5219F1AD.10004@zacarias.com.ar>
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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
prev parent reply other threads:[~2013-08-26 22:03 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
2013-08-25 9:11 ` Thomas Petazzoni
2013-08-25 11:59 ` Gustavo Zacarias
2013-08-26 22:03 ` Thomas Petazzoni [this message]
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=20130827000346.6abde816@skate \
--to=thomas.petazzoni@free-electrons.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox