diff mbox series

[1/1,v2] gcc: Add support for --enable-default-pie configure option.

Message ID 20171228214333.8340-1-stefan.froberg@petroprogram.com
State Changes Requested
Headers show
Series [1/1,v2] gcc: Add support for --enable-default-pie configure option. | expand

Commit Message

Stefan Fröberg Dec. 28, 2017, 9:43 p.m. UTC 
By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie".
With that enabled, GCC will produce PIE 
(Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization)
that will make exploits like return-to-libc attack impossible. 

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie
with your CFLAGS/CXXFLAGS.

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

Signed-off-by: Stefan Fröberg <stefan.froberg@petroprogram.com>
---
 package/gcc/Config.in.host | 10 ++++++++++
 package/gcc/gcc.mk         |  4 ++++
 2 files changed, 14 insertions(+)

Comments

Thomas Petazzoni Dec. 28, 2017, 10:07 p.m. UTC | #1 
Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
> By default, buildroot produces insecure binaries.
> 
> GCC 6.x added build time configuration option "--enable-default-pie".
> With that enabled, GCC will produce PIE 
> (Position-independent executables) binaries.
> 
> PIE is a requirement for ASLR (Address space layout randomization)
> that will make exploits like return-to-libc attack impossible. 
> 
> If you want to have a modern, secure system then enable this option.
> 
> To override this default behaviour, you can use -no-pie
> with your CFLAGS/CXXFLAGS.
> 
> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

As I said in my previous review, I think we want a solution that also
applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
options" in the mailing list archives,
https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie
support, but in a more generic way. Could you use this instead ?

Thanks!

Thomas
Matt Weber Dec. 28, 2017, 11:28 p.m. UTC | #2 
Stefan,

On Dec 28, 2017 4:08 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:

Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
> By default, buildroot produces insecure binaries.
>
> GCC 6.x added build time configuration option "--enable-default-pie".
> With that enabled, GCC will produce PIE
> (Position-independent executables) binaries.
>
> PIE is a requirement for ASLR (Address space layout randomization)
> that will make exploits like return-to-libc attack impossible.
>
> If you want to have a modern, secure system then enable this option.
>
> To override this default behaviour, you can use -no-pie
> with your CFLAGS/CXXFLAGS.
>
> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

As I said in my previous review, I think we want a solution that also
applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
options" in the mailing list archives,
https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie
support, but in a more generic way. Could you use this instead ?


I've got a v3 in the works for that one, I can incorporate this into it if
you'd like and send out the set this weekend (currently no computer)

Matt
<div dir="auto"><div>Stefan,<br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 28, 2017 4:08 PM, &quot;Thomas Petazzoni&quot; &lt;<a href="mailto:thomas.petazzoni@free-electrons.com">thomas.petazzoni@free-electrons.com</a>&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div class="quoted-text"><br>
On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:<br>
&gt; By default, buildroot produces insecure binaries.<br>
&gt;<br>
&gt; GCC 6.x added build time configuration option &quot;--enable-default-pie&quot;.<br>
&gt; With that enabled, GCC will produce PIE<br>
&gt; (Position-independent executables) binaries.<br>
&gt;<br>
&gt; PIE is a requirement for ASLR (Address space layout randomization)<br>
&gt; that will make exploits like return-to-libc attack impossible.<br>
&gt;<br>
&gt; If you want to have a modern, secure system then enable this option.<br>
&gt;<br>
&gt; To override this default behaviour, you can use -no-pie<br>
&gt; with your CFLAGS/CXXFLAGS.<br>
&gt;<br>
&gt; <a href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/<wbr>onlinedocs/gcc-6.2.0/gcc/Link-<wbr>Options.html</a><br>
<br>
</div>As I said in my previous review, I think we want a solution that also<br>
applies to external toolchains, by passing -pie in the compiler wrapper.<br>
<br>
Please see &quot;[PATCH 2/2] security hardening: add RELFO,  FORTIFY<br>
options&quot; in the mailing list archives,<br>
<a href="https://patchwork.ozlabs.org/patch/830085/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/<wbr>patch/830085/</a>, it was also adding -pie<br>
support, but in a more generic way. Could you use this instead ?<br>
<br><div class="elided-text"></div></blockquote></div></div></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I&#39;ve got a v3 in the works for that one, I can incorporate this into it if you&#39;d like and send out the set this weekend (currently no computer)</div><div dir="auto"><br></div><div dir="auto">Matt</div><div dir="auto"><br></div></div>
Stefan Fröberg Dec. 29, 2017, 1:25 p.m. UTC | #3 
Hi Thomas

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.

Either builtin (need GCC 6.x + ), with specs file (very ugly and messy
but also very effective) or maybe
compiler wrapper (call it "hardened-gcc/g++" or whatever) that I
remember Arnout Vandecappelle suggesting.

Best Regards
-S-



Thomas Petazzoni kirjoitti 29.12.2017 klo 00:07:
> Hello,
>
> On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
>> By default, buildroot produces insecure binaries.
>>
>> GCC 6.x added build time configuration option "--enable-default-pie".
>> With that enabled, GCC will produce PIE 
>> (Position-independent executables) binaries.
>>
>> PIE is a requirement for ASLR (Address space layout randomization)
>> that will make exploits like return-to-libc attack impossible. 
>>
>> If you want to have a modern, secure system then enable this option.
>>
>> To override this default behaviour, you can use -no-pie
>> with your CFLAGS/CXXFLAGS.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html
> As I said in my previous review, I think we want a solution that also
> applies to external toolchains, by passing -pie in the compiler wrapper.
>
> Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
> options" in the mailing list archives,
> https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie
> support, but in a more generic way. Could you use this instead ?
>
> Thanks!
>
> Thomas
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Thomas<br>
    <br>
    Yes, of course PIE (and other hardening flags) could be passed with<br>
    CFLAGS/CXXFLAGS/LDFLAGS.<br>
    <br>
    But what if some package does not care about
    CFLAGS/CXXFLAGS/LDFLAGS?<br>
    (Like for example, zlib by default does not do, but I see that
    buildroot maually passes them<br>
    to configure script)<br>
    <br>
    Then you would need to patch all those packages while with default
    PIE there would<br>
    be no need to patch. Compiler would automatically do the right thing<br>
    <br>
    And in the case of PIE, there seems to be tricky rules what to put
    and<br>
    where:<br>
    <a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/Changes/Harden_All_Packages">https://fedoraproject.org/wiki/Changes/Harden_All_Packages</a><br>
    <br>
    From the above link:<br>
    <br>
    "The key change is that for PIE builds, compilation for static
    linking <br>
    (such as object files which go into the main program, not a library)
    needs the flag <tt>-fPIE</tt>. <br>
    <br>
    But this flag <i>must not be included when compiling for dynamic
      linking</i> because the <br>
    resulting object code is not compatible with that. <br>
    <br>
    To repeat, <i>*you should not specify both <tt>-fpic</tt> and <tt>-fpie</tt>
      on the same command line</i>* <br>
    because this rarely has the intended effect.
    "<br>
    <br>
    So with default pie built into compiler, the compiler would
    automatically do the right thing.<br>
    <br>
    Other than letting compiler to handle the PIE and changing
    "fstack-protector-all" to <br>
    "fstack-protector-strong"  (introduced in GCC 4.9, pretty much the
    same result that "all" but with less performance penalty)<br>
    that generic hardening patch looks okay to me.<br>
    <br>
    So I suggest that let the compiler handle PIE.<br>
    <br>
    Either builtin (need GCC 6.x + ), with specs file (very ugly and
    messy but also very effective) or maybe<br>
    compiler wrapper (call it "hardened-gcc/g++" or whatever) that I
    remember Arnout Vandecappelle suggesting.<br>
    <br>
    Best Regards<br>
    -S-<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">Thomas Petazzoni kirjoitti 29.12.2017
      klo 00:07:<br>
    </div>
    <blockquote type="cite" cite="mid:20171228230743.1e6c59ab@windsurf">
      <pre wrap="">Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie".
With that enabled, GCC will produce PIE 
(Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization)
that will make exploits like return-to-libc attack impossible. 

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie
with your CFLAGS/CXXFLAGS.

<a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html">https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html</a>
</pre>
      </blockquote>
      <pre wrap="">
As I said in my previous review, I think we want a solution that also
applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
options" in the mailing list archives,
<a class="moz-txt-link-freetext" href="https://patchwork.ozlabs.org/patch/830085/">https://patchwork.ozlabs.org/patch/830085/</a>, it was also adding -pie
support, but in a more generic way. Could you use this instead ?

Thanks!

Thomas
</pre>
    </blockquote>
    <br>
  </body>
</html>
Stefan Fröberg Dec. 29, 2017, 1:34 p.m. UTC | #4 
Actually, now that I think of it...there is also --enable-default-ssp
flag too to
let compiler handle stack-protection automatically too

https://gcc.gnu.org/install/configure.html

|"--enable-default-ssp|
    Turn on -fstack-protector-strong by default. "


-S-


Stefan Fröberg kirjoitti 29.12.2017 klo 15:25:
> Hi Thomas
>
> 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.
>
> Either builtin (need GCC 6.x + ), with specs file (very ugly and messy
> but also very effective) or maybe
> compiler wrapper (call it "hardened-gcc/g++" or whatever) that I
> remember Arnout Vandecappelle suggesting.
>
> Best Regards
> -S-
>
>
>
> Thomas Petazzoni kirjoitti 29.12.2017 klo 00:07:
>> Hello,
>>
>> On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
>>> By default, buildroot produces insecure binaries.
>>>
>>> GCC 6.x added build time configuration option "--enable-default-pie".
>>> With that enabled, GCC will produce PIE 
>>> (Position-independent executables) binaries.
>>>
>>> PIE is a requirement for ASLR (Address space layout randomization)
>>> that will make exploits like return-to-libc attack impossible. 
>>>
>>> If you want to have a modern, secure system then enable this option.
>>>
>>> To override this default behaviour, you can use -no-pie
>>> with your CFLAGS/CXXFLAGS.
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html
>> As I said in my previous review, I think we want a solution that also
>> applies to external toolchains, by passing -pie in the compiler wrapper.
>>
>> Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
>> options" in the mailing list archives,
>> https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie
>> support, but in a more generic way. Could you use this instead ?
>>
>> Thanks!
>>
>> Thomas
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Actually, now that I think of it...there is also
    --enable-default-ssp flag too to <br>
    let compiler handle stack-protection automatically too<br>
    <br>
    <a class="moz-txt-link-freetext" href="https://gcc.gnu.org/install/configure.html">https://gcc.gnu.org/install/configure.html</a><br>
    <dl compact="compact">
      <dt><code>"--enable-default-ssp</code></dt>
      <dd>Turn on <samp>-fstack-protector-strong</samp> by default.
        "<br>
      </dd>
    </dl>
    <p><br>
    </p>
    <p>-S-<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Stefan Fröberg kirjoitti 29.12.2017 klo
      15:25:<br>
    </div>
    <blockquote type="cite"
      cite="mid:5a5a8ab0-25f3-a3a2-bf5a-b9c7fe851c66@petroprogram.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Hi Thomas<br>
      <br>
      Yes, of course PIE (and other hardening flags) could be passed
      with<br>
      CFLAGS/CXXFLAGS/LDFLAGS.<br>
      <br>
      But what if some package does not care about
      CFLAGS/CXXFLAGS/LDFLAGS?<br>
      (Like for example, zlib by default does not do, but I see that
      buildroot maually passes them<br>
      to configure script)<br>
      <br>
      Then you would need to patch all those packages while with default
      PIE there would<br>
      be no need to patch. Compiler would automatically do the right
      thing<br>
      <br>
      And in the case of PIE, there seems to be tricky rules what to put
      and<br>
      where:<br>
      <a class="moz-txt-link-freetext"
        href="https://fedoraproject.org/wiki/Changes/Harden_All_Packages"
        moz-do-not-send="true">https://fedoraproject.org/wiki/Changes/Harden_All_Packages</a><br>
      <br>
      From the above link:<br>
      <br>
      "The key change is that for PIE builds, compilation for static
      linking <br>
      (such as object files which go into the main program, not a
      library) needs the flag <tt>-fPIE</tt>. <br>
      <br>
      But this flag <i>must not be included when compiling for dynamic
        linking</i> because the <br>
      resulting object code is not compatible with that. <br>
      <br>
      To repeat, <i>*you should not specify both <tt>-fpic</tt> and <tt>-fpie</tt>
        on the same command line</i>* <br>
      because this rarely has the intended effect. "<br>
      <br>
      So with default pie built into compiler, the compiler would
      automatically do the right thing.<br>
      <br>
      Other than letting compiler to handle the PIE and changing
      "fstack-protector-all" to <br>
      "fstack-protector-strong"  (introduced in GCC 4.9, pretty much the
      same result that "all" but with less performance penalty)<br>
      that generic hardening patch looks okay to me.<br>
      <br>
      So I suggest that let the compiler handle PIE.<br>
      <br>
      Either builtin (need GCC 6.x + ), with specs file (very ugly and
      messy but also very effective) or maybe<br>
      compiler wrapper (call it "hardened-gcc/g++" or whatever) that I
      remember Arnout Vandecappelle suggesting.<br>
      <br>
      Best Regards<br>
      -S-<br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">Thomas Petazzoni kirjoitti 29.12.2017
        klo 00:07:<br>
      </div>
      <blockquote type="cite"
        cite="mid:20171228230743.1e6c59ab@windsurf">
        <pre wrap="">Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fröberg wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie".
With that enabled, GCC will produce PIE 
(Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization)
that will make exploits like return-to-libc attack impossible. 

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie
with your CFLAGS/CXXFLAGS.

<a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html" moz-do-not-send="true">https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html</a>
</pre>
        </blockquote>
        <pre wrap="">As I said in my previous review, I think we want a solution that also
applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO,  FORTIFY
options" in the mailing list archives,
<a class="moz-txt-link-freetext" href="https://patchwork.ozlabs.org/patch/830085/" moz-do-not-send="true">https://patchwork.ozlabs.org/patch/830085/</a>, it was also adding -pie
support, but in a more generic way. Could you use this instead ?

Thanks!

Thomas
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
buildroot mailing list
<a class="moz-txt-link-abbreviated" href="mailto:buildroot@busybox.net">buildroot@busybox.net</a>
<a class="moz-txt-link-freetext" href="http://lists.busybox.net/mailman/listinfo/buildroot">http://lists.busybox.net/mailman/listinfo/buildroot</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>
Thomas Petazzoni Dec. 29, 2017, 1:42 p.m. UTC | #5 
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
Stefan Fröberg Dec. 29, 2017, 1:48 p.m. UTC | #6 
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
Thomas Petazzoni Dec. 29, 2017, 2:04 p.m. UTC | #7 
Hello,

On Fri, 29 Dec 2017 15:48:48 +0200, Stefan Fröberg wrote:

> 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...).

And since the different method needed for external toolchains would
also work for internal toolchains, there is no point in doing a
solution that only works for internal toolchains. See my point ?

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

We generally try to have internal and external toolchains supported in
the same way. You may only be interested in internal toolchains, but
Buildroot as a project needs to keep the feature parity between
internal and external toolchains, so we would like to have a solution
that solves both situations.

Thomas
Stefan Fröberg Dec. 30, 2017, 2:34 a.m. UTC | #8 
Hello


Thomas Petazzoni kirjoitti 29.12.2017 klo 16:04:
> Hello,
>
> On Fri, 29 Dec 2017 15:48:48 +0200, Stefan Fröberg wrote:
>
>> 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...).
> And since the different method needed for external toolchains would
> also work for internal toolchains, there is no point in doing a
> solution that only works for internal toolchains. See my point ?

Except can you be absolute sure that -fpic and -fpie will never happen
in the same commandline
when using just flags?

>> Personally, Im only interested of internal toolchain
>> (and I think this is not the first case that internal/external
>> toolchains have different rules?)
> We generally try to have internal and external toolchains supported in
> the same way. You may only be interested in internal toolchains, but
> Buildroot as a project needs to keep the feature parity between
> internal and external toolchains, so we would like to have a solution
> that solves both situations.
>
> Thomas

Actually, not true. You already have options like "Enable compiler
link-time-optimization support",
"Enable compiler OpenMP support" and "Enable graphite support".
(with pretty spartan description I might add)

All those are optimization related, activated by built-time
configuration switches.
Mine is security related and also activated by built-time configuration
switch.

And when selecting External toolchain then ...*poof* ... they all vanish
into the air.

So if buildroot would really treat both external and internal toolchain
equally then those options should
also be added when using external toolchain.

-S-
diff mbox series

Patch

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 70cce0a5c5..bf646fa07b 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -152,3 +152,13 @@  config BR2_GCC_ENABLE_GRAPHITE
 
 comment "graphite support needs gcc >= 5.x"
 	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5
+
+config BR2_GCC_ENABLE_DEFAULT_PIE
+	bool "Enable default PIE support"
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_6
+	help
+	  This option enables the GCC to make PIE
+	  binaries by default.
+
+comment "default PIE support needs gcc >= 6.x"
+	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_6
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 27fc1e987c..0910fb3932 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -183,6 +183,10 @@  else
 HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
 endif
 
+ifeq ($(BR2_GCC_ENABLE_DEFAULT_PIE),y)
+HOST_GCC_COMMON_CONF_OPTS += --enable-default-pie
+endif
+
 ifeq ($(BR2_arc)$(BR2_or1k),y)
 HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
 endif