Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.
Date: Fri, 29 Dec 2017 15:48:48 +0200	[thread overview]
Message-ID: <3ca77bc6-5613-bc51-be89-0b241fd6d204@petroprogram.com> (raw)
In-Reply-To: <20171229144204.00605c4e@windsurf.lan>

Yeah, there is no other way for external toolchains than generic flags
passing (and possibly patching)
or compiler wrapper (well, there is specs file but it's ...soooo messy...).

Personally, Im only interested of internal toolchain
(and I think this is not the first case that internal/external
toolchains have different rules?)

-S-

Thomas Petazzoni kirjoitti 29.12.2017 klo 15:42:
> Hello,
>
> On Fri, 29 Dec 2017 15:25:21 +0200, Stefan Fr?berg wrote:
>
>> Yes, of course PIE (and other hardening flags) could be passed with
>> CFLAGS/CXXFLAGS/LDFLAGS.
>>
>> But what if some package does not care about CFLAGS/CXXFLAGS/LDFLAGS?
>> (Like for example, zlib by default does not do, but I see that buildroot
>> maually passes them
>> to configure script)
>>
>> Then you would need to patch all those packages while with default PIE
>> there would
>> be no need to patch. Compiler would automatically do the right thing
>>
>> And in the case of PIE, there seems to be tricky rules what to put and
>> where:
>> https://fedoraproject.org/wiki/Changes/Harden_All_Packages
>>
>> From the above link:
>>
>> "The key change is that for PIE builds, compilation for static linking
>> (such as object files which go into the main program, not a library)
>> needs the flag -fPIE.
>>
>> But this flag /must not be included when compiling for dynamic linking/
>> because the
>> resulting object code is not compatible with that.
>>
>> To repeat, /*you should not specify both -fpic and -fpie on the same
>> command line/*
>> because this rarely has the intended effect. "
>>
>> So with default pie built into compiler, the compiler would
>> automatically do the right thing.
>>
>> Other than letting compiler to handle the PIE and changing
>> "fstack-protector-all" to
>> "fstack-protector-strong"? (introduced in GCC 4.9, pretty much the same
>> result that "all" but with less performance penalty)
>> that generic hardening patch looks okay to me.
>>
>> So I suggest that let the compiler handle PIE.
> And what do you propose for external toolchains ?
>
> That's the big limitation in your proposal: it works fine for the
> internal toolchain, but doesn't work at all for the external toolchain.
> Hence the discussion on using CFLAGS, or the compiler wrapper.
>
> Thomas

  reply	other threads:[~2017-12-29 13:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 21:43 [Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option Stefan Fröberg
2017-12-28 22:07 ` Thomas Petazzoni
     [not found]   ` <CANQCQpZ40Q3T2gOPqu8_vGHCTAup_fxgW3ubfYjewfgo7DwW0A@mail.gmail.com>
2017-12-28 23:28     ` Matthew Weber
2017-12-29 13:25   ` Stefan Fröberg
2017-12-29 13:34     ` Stefan Fröberg
2017-12-29 13:42     ` Thomas Petazzoni
2017-12-29 13:48       ` Stefan Fröberg [this message]
2017-12-29 14:04         ` Thomas Petazzoni
2017-12-30  2:34           ` Stefan Fröberg

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=3ca77bc6-5613-bc51-be89-0b241fd6d204@petroprogram.com \
    --to=stefan.froberg@petroprogram.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