From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Al Viro <viro@ZenIV.linux.org.uk>
Cc: Ben Hutchings <ben@decadent.org.uk>,
linux-kernel@vger.kernel.org, Sven Joachim <svenjoac@gmx.de>,
Tomas Janousek <tomi@nomi.cz>, Joe Perches <joe@perches.com>,
Adam Borowski <kilobyte@angband.pl>,
Michal Marek <mmarek@suse.com>,
linux-kbuild@vger.kernel.org, doko@debian.org
Subject: Re: [PATCH 2/2] kbuild: add -fno-PIE
Date: Fri, 4 Nov 2016 10:47:37 -0400 [thread overview]
Message-ID: <1f21026c-c2b0-bc12-f891-dcdbca0759b8@gmail.com> (raw)
In-Reply-To: <20161104142424.jy6ble3pge3beowh@linutronix.de>
On 2016-11-04 10:24, Sebastian Andrzej Siewior wrote:
> On 2016-11-04 07:37:02 [-0400], Austin S. Hemmelgarn wrote:
>>> clued enough to have known better. Reassigning bug reports in question
>>> from gcc-6 to linux is beyond stupid; Balint is either being deliberately
>>> obtuse, or geniunely unable to imagine that somebody might be using the
>>> compiler _not_ for debian package builds.
>>>
>> If it helps, you could point out that Gentoo's hardened profile's GCC builds
>> use PIE by default and have absolutely zero issues building the Linux kernel
>> without any special kernel patches to turn it off (and has been doing so for
>> years).
>
> Interesting. So I took a look at Gentoo. They ship gcc 4.9.3 by default.
> They have their own PIE patch since it is not yet supported by gcc. And
> let me quote why that works for them:
>
> | This file will add -fstack-protector-all, -fstack-check, -fPIE, -pie and -z now
> | as default if the defines and the spec allow it.
> | Added a hack for gcc-specs-* in toolchain-funcs.eclass and _filter-hardened in flag-o-matic.eclass
> | to support older hardened GCC patches and we don't need to change the code on gcc-specs-* and _filter-hardened.
> | This will add some unsupported upstream commands options as -nopie and -nonow.
> | -D__KERNEL__ is added so we don't have -fPIE, -pie and -fstack-protector-all and -fstack-check when building kernels.
> | ESP_CC1_SPEC is added to CC1_SPEC.
> | ESP_CC1_STRICT_OVERFLOW_SPEC is added so we don't disable the strict-overflow check.
> | ESP_LINK_PIE_CHECK_SPEC check for -pie, -p, -pg, -profile and -static.
> | ENABLE_CRTBEGINP add support for crtbeginP.o, build -static with -fPIE or -fpie.
>
> I was thinking about asking doko for something similar but no. Looking at
> portage they have a few patches where they add -fno-PIE to some packages.
> Also disabling PIE based on __KERNEL__ does not look right. So no, Gentoo
> did not better.
> And according to Google, there are also people in the ARCH Linux camp
> with the same problem. Gentoo's 6 gcc is completely masked and it does
> not reference the patch I quote above so Gentoo will run into this
> problem once they enable gcc 6 and don't add the -D__KERNEL__ hack.
> Eventually Fedora and SUSE will migrate to PIE by default and by then we
> should cover all major distros so even Al should be affected unless he
> decides not to update or is using something else.
While I don't agree with _how_ they worked around it, it still works
correctly with no user intervention for pretty much every important
case, and my point was more that it is possible to make this work
without a kernel patch than 'Hey, it works over here, lets do what
they're doing'.
I would still argue that the root of the issue is how GCC handles
options specified on the command line that conflict with it's compile
time defaults. This is at least the second kernel related case where
things broke because GCC doesn't do the sensible thing and override
defaults based on command line options (there is (or was, not sure if
it's been resolved yet or not) an issue too on MIPS with some other
option that I can't remember right now). If option X and option Y are
mutually exclusive, and option X is specified on the command line while
option Y isn't, they should not use option Y regardless of whether or
not it's the default and possibly spit out a warning if it is the
default (for PIC, yes, there probably should be a warning), not die.
next prev parent reply other threads:[~2016-11-04 14:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 17:20 [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils Sebastian Andrzej Siewior
2016-11-02 17:20 ` [PATCH 2/2] kbuild: add -fno-PIE Sebastian Andrzej Siewior
2016-11-03 22:50 ` Ben Hutchings
2016-11-04 1:08 ` Al Viro
2016-11-04 11:37 ` Austin S. Hemmelgarn
2016-11-04 14:24 ` Sebastian Andrzej Siewior
2016-11-04 14:39 ` Markus Trippelsdorf
2016-11-04 14:55 ` Austin S. Hemmelgarn
2016-11-04 14:47 ` Austin S. Hemmelgarn [this message]
2016-11-04 15:18 ` Al Viro
2016-11-04 15:22 ` Christoph Hellwig
2016-11-04 15:54 ` Al Viro
2016-11-04 15:58 ` Sebastian Andrzej Siewior
2016-11-04 16:10 ` Al Viro
2016-11-04 16:17 ` Sebastian Andrzej Siewior
2016-11-04 16:25 ` Adam Borowski
2016-11-02 18:52 ` [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils Sven Joachim
2016-11-02 19:55 ` Borislav Petkov
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=1f21026c-c2b0-bc12-f891-dcdbca0759b8@gmail.com \
--to=ahferroin7@gmail.com \
--cc=ben@decadent.org.uk \
--cc=bigeasy@linutronix.de \
--cc=doko@debian.org \
--cc=joe@perches.com \
--cc=kilobyte@angband.pl \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.com \
--cc=svenjoac@gmx.de \
--cc=tomi@nomi.cz \
--cc=viro@ZenIV.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).