From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] package/Makefile.in: Do not use CPPFLAGS for hardening options
Date: Wed, 25 Apr 2018 22:30:45 +0200 [thread overview]
Message-ID: <20180425223045.7d20bd11@windsurf> (raw)
In-Reply-To: <CANQCQpbaywbogjHpXaiQkBsS1Sas2R7tJiP2yW8mfxHrqq2_oQ@mail.gmail.com>
Hello,
On Wed, 25 Apr 2018 07:50:37 -0500, Matthew Weber wrote:
> Thanks for sending this series. When we added the initial support we
> debated on doing a few things differently at some point with how this
> is implemented. First, Buildroot uses a toolchain wrapper where it
> could inject these flags vs appending like the current design does.
> This would allow all the packages with flag ordering issues and no
> formal releases, to not carry a patch in buildroot for the long term.
For the record: there is no flag ordering issue with PIE, contrary to
what we discussed in Brussels.
I think it is something I discussed further with my colleague Antoine
Tenart (in Cc). Basically, the issue is not that there is an ordering
requirement between -pie and -shared. The issue is that -pie and
-shared are incompatible with each other.
Passing -pie before -shared just papers over the problem, and basically
-shared "wins". Indeed, there is no point for a shared library to be
compiled PIE. PIE only makes sense for executables. Shared libraries
already need to be compiled as PIC, regardless of whether PIE is used
or not for executables.
The issue is of course that we hardly have control over when PIE is
used vs. PIC. But I think it's important to make it clear what the
exact problem is: it's not a flag ordering problem.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-04-25 20:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 6:45 [Buildroot] [PATCH 1/4] package/Makefile.in: Do not use CPPFLAGS for hardening options Stefan Sørensen
2018-04-25 6:45 ` [Buildroot] [PATCH 2/4] package/Makefile.in: Add missing options to LDFLAGS for full RELRO build Stefan Sørensen
2018-05-01 15:12 ` Matthew Weber
2018-04-25 6:45 ` [Buildroot] [PATCH 3/4] package/Makefile.in: Remove RELRO linker flags from CFLAGS Stefan Sørensen
2018-04-30 17:57 ` Matthew Weber
2018-05-01 15:05 ` Matthew Weber
2018-05-02 21:54 ` Arnout Vandecappelle
2018-05-03 16:07 ` Matthew Weber
2018-04-25 6:45 ` [Buildroot] [PATCH 4/4] package/Makefile.in: Use gcc spec files for PIE build flags Stefan Sørensen
2018-05-01 15:13 ` Matthew Weber
2018-05-01 15:36 ` Matthew Weber
2018-05-02 22:28 ` Arnout Vandecappelle
2018-04-25 12:50 ` [Buildroot] [PATCH 1/4] package/Makefile.in: Do not use CPPFLAGS for hardening options Matthew Weber
2018-04-25 13:08 ` Sørensen, Stefan
2018-04-25 13:12 ` Matthew Weber
2018-04-25 13:25 ` Sørensen, Stefan
2018-04-25 20:57 ` Thomas Petazzoni
2018-04-25 20:30 ` Thomas Petazzoni [this message]
2018-04-27 13:09 ` 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=20180425223045.7d20bd11@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