linux-kernel - Re: [PATCH 2/2] kbuild: add -fno-PIE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4dfe9ff4-ed5a-ef6f-c5a3-a9dbb87d4e6f@gmail.com>
Date:   Fri, 4 Nov 2016 10:55:51 -0400
From:   "Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:     Markus Trippelsdorf <markus@...ppelsdorf.de>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Al Viro <viro@...IV.linux.org.uk>,
        Ben Hutchings <ben@...adent.org.uk>,
        linux-kernel@...r.kernel.org, Sven Joachim <svenjoac@....de>,
        Tomas Janousek <tomi@...i.cz>, Joe Perches <joe@...ches.com>,
        Adam Borowski <kilobyte@...band.pl>,
        Michal Marek <mmarek@...e.com>, linux-kbuild@...r.kernel.org,
        doko@...ian.org
Subject: Re: [PATCH 2/2] kbuild: add -fno-PIE

On 2016-11-04 10:39, Markus Trippelsdorf wrote:
> On 2016.11.04 at 15:24 +0100, 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.
>
> But why enable PIE by default? What additional security does one gain if
> e.g. "cat" or "dmesg" are position independent executables?
> It also adds overhead (,although this is smaller than it used to be on
> X86_64).
> So instead of doing the sane thing and adding -fPIE to long running
> daemons only, now many project have to add -fno-pie to avoid breakage.
>
Actually, the number of things that don't work with PIE is pretty small 
(pretty much kernel code and some stuff that does in-line assembly).

In general, it falls under the heading of 'secure by default'.  Yeah, 
some stuff like cat and dmesg have essentially zero security benefit 
from being compiled with -fPIE, but once you start looking at pretty 
much anything that's doing any processing of potentially untrusted data 
(which includes anything that talks to the network), you do start having 
some security improvement.