From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/6] package/Makefile.in: Use gcc spec files for PIE build flags
Date: Sun, 12 Aug 2018 17:07:03 +0200 [thread overview]
Message-ID: <20180812170703.06be88df@windsurf> (raw)
In-Reply-To: <CANQCQpam_kU+CdNETW7g9N49MgRhRj6tEQNc8qayzGdJiTWC_A@mail.gmail.com>
Hello,
On Sun, 12 Aug 2018 07:49:19 -0500, Matthew Weber wrote:
> > So I don't think we need to wrap "ld", as ld shouldn't be used
> > directly. The only packages that should use "ld" directly are things
> > like the Linux kernel or bootloaders.
>
> The current hardening approach is trying to cover the cases where
> packages are still using ld directly and have other incompatible flags
> set (static/shared/r). I don't have the exact list but I believe
> busybox is even one of those and others like valgrind, boost, etc who
> use the "shared" flag and adding "pie" causes a compile failure. So
> we do still need to cover the ld case or go patch packages.
I find it weird that those packages are using "ld" directly, because if
that's the case, we would have build failures on some mips64
configurations.
> What I could do is move the cc1 spec file conditional add of PIE into
> the wrapper. Then leave the LDFLAGS as we have them and the
> associated spec file that does a conditional add of "pie". This would
> prevent us from wrapping the ld tool and keep the existing wrapper
> approach consistent.
If we really need to do some custom logic around ld, then I believe I'd
prefer to have a wrapper for it as well, to keep things consistent. But
of course, Arnout's opinion on the matter would be welcome.
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-08-12 15:07 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 14:31 [Buildroot] [PATCH 0/6] Hardening Flag Bugfix/Enhancement Matt Weber
2018-07-11 14:31 ` [Buildroot] [PATCH 1/6] package/Makefile.in: Do not use CPPFLAGS for hardening options Matt Weber
2018-07-11 21:14 ` Arnout Vandecappelle
2018-08-10 20:31 ` Thomas Petazzoni
2018-07-11 14:31 ` [Buildroot] [PATCH 2/6] package/Makefile.in: Add missing options to LDFLAGS for full RELRO build Matt Weber
2018-07-11 21:26 ` Arnout Vandecappelle
2018-08-10 20:33 ` Thomas Petazzoni
2018-07-11 14:31 ` [Buildroot] [PATCH 3/6] package/Makefile.in: Use gcc spec files for PIE build flags Matt Weber
2018-07-11 21:44 ` Arnout Vandecappelle
2018-07-11 23:17 ` Matthew Weber
2018-07-13 9:39 ` Arnout Vandecappelle
2018-07-13 12:31 ` Matthew Weber
2018-07-19 9:49 ` Sørensen, Stefan
2018-07-19 12:58 ` Matthew Weber
2018-07-19 13:10 ` Sørensen, Stefan
2018-08-07 17:02 ` Matthew Weber
2018-08-07 17:20 ` Matthew Weber
2018-08-08 7:24 ` Jan Kundrát
2018-08-08 8:35 ` Jan Kundrát
2018-08-08 11:38 ` Matthew Weber
2018-08-09 14:32 ` Matthew Weber
2018-08-28 20:07 ` Matthew Weber
2018-08-10 20:50 ` Thomas Petazzoni
2018-08-11 0:42 ` Matthew Weber
2018-08-11 10:29 ` Thomas Petazzoni
2018-08-12 3:55 ` Matthew Weber
2018-08-12 7:41 ` Thomas Petazzoni
2018-08-12 12:49 ` Matthew Weber
2018-08-12 15:07 ` Thomas Petazzoni [this message]
2018-08-12 21:20 ` Arnout Vandecappelle
2018-07-11 14:31 ` [Buildroot] [PATCH 4/6] support/testing: runtest proxy support Matt Weber
2018-07-11 21:47 ` Arnout Vandecappelle
2018-08-10 20:51 ` Thomas Petazzoni
2018-08-11 0:30 ` Matthew Weber
2018-08-11 1:03 ` Matthew Weber
2018-07-11 14:31 ` [Buildroot] [PATCH 5/6] package/checksec: new package Matt Weber
2018-08-10 20:58 ` Thomas Petazzoni
2018-08-11 0:57 ` Matthew Weber
2018-08-11 10:30 ` Thomas Petazzoni
2018-07-11 14:31 ` [Buildroot] [PATCH 6/6] support/testing/tests/core: SSP & hardening flags Matt Weber
2018-07-16 1:32 ` Ricardo Martincoski
2018-07-17 2:53 ` Matthew Weber
2018-07-17 3:05 ` Matthew Weber
2018-07-12 11:44 ` [Buildroot] [PATCH 0/6] Hardening Flag Bugfix/Enhancement Matthew Weber
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=20180812170703.06be88df@windsurf \
--to=thomas.petazzoni@bootlin.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