[PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[Sebastian Andrzej Siewior]

Debian Woody is pre-gcc3.2 and Sarge ships 3.3 gcc. I tried to compile
v4.8.6 on Sarge failed due to binutils:
|arch/x86/entry/entry_32.S: Assembler messages:
|arch/x86/entry/entry_32.S:379: Error: invalid character '"' in operand 1
|arch/x86/entry/entry_32.S:454: Error: too many positional arguments
|arch/x86/entry/entry_32.S:580: Error: too many positional arguments
|arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit base/index expression

among other errors. Sarge comes with GNU ld version 2.15 with is not
recent enough. I don't see those errors on Etch which ships version 2.17
and therefore I raise the limit to 2.17.
gcc is a different story. 3.3 It throws a lot of warnings
|include/linux/irq.h:402: warning: parameter has incomplete type
|include/linux/irq.h:403: warning: parameter has incomplete type
|drivers/gpu/drm/i915/i915_gem_gtt.h:312: warning: parameter has incomplete type

during the compile and fails then with
| cc1: error: unrecognized option `-Wno-override-init'

or later with

|lib/lzo/lzo1x_compress.c: In function `lzo1x_1_do_compress':
|lib/lzo/lzo1x_compress.c:132: error: implicit declaration of function `__builtin_ctz'

Etch (with gcc v4.1.2) gets to compile the kernel without plenty of
warnings and it also chokes on Wno-override-init but that one could be
easily fixed if we want to keep v4.1 as the minimum.
So I think raising the bar to gcc v4.1 isn't that bad given that the
last release of gcc 4.1 was on February 13, 2007.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 Documentation/Changes | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/Changes b/Documentation/Changes
index 22797a15dc24..14e65b445707 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -29,9 +29,9 @@ you probably needn't concern yourself with isdn4k-utils.
 ====================== ===============  ========================================
         Program        Minimal version       Command to check the version
 ====================== ===============  ========================================
-GNU C                  3.2              gcc --version
+GNU C                  4.1              gcc --version
 GNU make               3.80             make --version
-binutils               2.12             ld -v
+binutils               2.17             ld -v
 util-linux             2.10o            fdformat --version
 module-init-tools      0.9.10           depmod -V
 e2fsprogs              1.41.4           e2fsck -V
-- 
2.10.2

[PATCH 2/2] kbuild: add -fno-PIE

[Sebastian Andrzej Siewior]

Debian started to build the gcc with -fPIE by default so the kernel
build ends before it starts properly with:
|kernel/bounds.c:1:0: error: code model kernel does not support PIC mode

Also add to KBUILD_AFLAGSi due to:

|gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
|arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in c ombination with -fpic

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 93beca4312c4..3e0a9afa428f 100644
--- a/Makefile
+++ b/Makefile
@@ -398,12 +398,12 @@ KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		   -fno-strict-aliasing -fno-common \
 		   -Werror-implicit-function-declaration \
-		   -Wno-format-security \
+		   -Wno-format-security -fno-PIE \
 		   -std=gnu89
 
 KBUILD_AFLAGS_KERNEL :=
 KBUILD_CFLAGS_KERNEL :=
-KBUILD_AFLAGS   := -D__ASSEMBLY__
+KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
 KBUILD_AFLAGS_MODULE  := -DMODULE
 KBUILD_CFLAGS_MODULE  := -DMODULE
 KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
-- 
2.10.2

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Wed, 2016-11-02 at 18:20 +0100, Sebastian Andrzej Siewior wrote:
> Debian started to build the gcc with -fPIE by default so the kernel
> build ends before it starts properly with:
> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
> 
> 
> Also add to KBUILD_AFLAGSi due to:
> 
> |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
> |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in c ombination with -fpic
[...]

Unfortunately this isn't sufficient:

Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
/build/linux-4.9~rc3/Makefile:1069: recipe for target 'prepare-compiler-check' failed
make[5]: *** [prepare-compiler-check] Error 1

scripts/gcc-x86_64-has-stack-protector.sh has its own list of options
which will need to include -fno-PIE.

Ben.

-- 
Ben Hutchings
The world is coming to an end.	Please log off.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Al Viro]

On Thu, Nov 03, 2016 at 04:50:55PM -0600, Ben Hutchings wrote:
> On Wed, 2016-11-02 at 18:20 +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
> > 
> > 
> > Also add to KBUILD_AFLAGSi due to:
> > 
> > |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
> > |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in c ombination with -fpic
> [...]
> 
> Unfortunately this isn't sufficient:
> 
> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
> /build/linux-4.9~rc3/Makefile:1069: recipe for target 'prepare-compiler-check' failed
> make[5]: *** [prepare-compiler-check] Error 1
> 
> scripts/gcc-x86_64-has-stack-protector.sh has its own list of options
> which will need to include -fno-PIE.

That shit should be fixed in debian; no amount of kbuild changes will help
on bisect going back to a state prior to those.  IOW, no matter what we
do kernel-side, that fuckup by doku, balint, et.al. needs to be fixed in
debian gcc package.

Al, seriously disappointed by that mess - debian gcc packagers are generally
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.

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

[Austin S. Hemmelgarn]

On 2016-11-03 21:08, Al Viro wrote:
> On Thu, Nov 03, 2016 at 04:50:55PM -0600, Ben Hutchings wrote:
>> On Wed, 2016-11-02 at 18:20 +0100, Sebastian Andrzej Siewior wrote:
>>> Debian started to build the gcc with -fPIE by default so the kernel
>>> build ends before it starts properly with:
>>> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>>>
>>>
>>> Also add to KBUILD_AFLAGSi due to:
>>>
>>> |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
>>> |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in c ombination with -fpic
>> [...]
>>
>> Unfortunately this isn't sufficient:
>>
>> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
>> /build/linux-4.9~rc3/Makefile:1069: recipe for target 'prepare-compiler-check' failed
>> make[5]: *** [prepare-compiler-check] Error 1
>>
>> scripts/gcc-x86_64-has-stack-protector.sh has its own list of options
>> which will need to include -fno-PIE.
>
> That shit should be fixed in debian; no amount of kbuild changes will help
> on bisect going back to a state prior to those.  IOW, no matter what we
> do kernel-side, that fuckup by doku, balint, et.al. needs to be fixed in
> debian gcc package.
>
> Al, seriously disappointed by that mess - debian gcc packagers are generally
> 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).

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

[Sebastian Andrzej Siewior]

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.

Sebastian

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

[Markus Trippelsdorf]

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.

-- 
Markus

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

[Austin S. Hemmelgarn]

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.

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

[Austin S. Hemmelgarn]

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.

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

[Al Viro]

On Fri, Nov 04, 2016 at 03:24:24PM +0100, Sebastian Andrzej Siewior wrote:

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

That "something else" happens to be mostly Debian, actually.

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

[Christoph Hellwig]

On Fri, Nov 04, 2016 at 03:18:11PM +0000, Al Viro wrote:
> On Fri, Nov 04, 2016 at 03:24:24PM +0100, Sebastian Andrzej Siewior wrote:
> 
> > 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.
> 
> That "something else" happens to be mostly Debian, actually.

Debian is moving over to PIE already.  Looks at this for example:

https://lists.debian.org/debian-kernel/2016/10/msg00242.html

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

[Al Viro]

On Fri, Nov 04, 2016 at 08:22:23AM -0700, Christoph Hellwig wrote:
> On Fri, Nov 04, 2016 at 03:18:11PM +0000, Al Viro wrote:
> > On Fri, Nov 04, 2016 at 03:24:24PM +0100, Sebastian Andrzej Siewior wrote:
> > 
> > > 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.
> > 
> > That "something else" happens to be mostly Debian, actually.
> 
> Debian is moving over to PIE already.  Looks at this for example:
> 
> https://lists.debian.org/debian-kernel/2016/10/msg00242.html

Christoph, would you mind rereading what I posted upthread?  I *am* aware of
that clusterfuck, including the Balint's charming games with the reassignments,
etc.  Directly affected by the whole mess, actually.

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

[Sebastian Andrzej Siewior]

On 2016-11-04 15:54:27 [+0000], Al Viro wrote:
> Christoph, would you mind rereading what I posted upthread?  I *am* aware of
> that clusterfuck, including the Balint's charming games with the reassignments,
> etc.  Directly affected by the whole mess, actually.

Al, I am re-doing the patch with a runtime check for -fno-PIE and
tagging it stable and looking after Ben's fstack protector thingy.
This should allow you to compile maintained stable kernels but it won't
allow you to bisect to prior versions.
I don't see any other way around it.

Sebastian

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

[Al Viro]

On Fri, Nov 04, 2016 at 04:58:55PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-04 15:54:27 [+0000], Al Viro wrote:
> > Christoph, would you mind rereading what I posted upthread?  I *am* aware of
> > that clusterfuck, including the Balint's charming games with the reassignments,
> > etc.  Directly affected by the whole mess, actually.
> 
> Al, I am re-doing the patch with a runtime check for -fno-PIE and
> tagging it stable and looking after Ben's fstack protector thingy.
> This should allow you to compile maintained stable kernels but it won't
> allow you to bisect to prior versions.
> I don't see any other way around it.

And I don't see any way around severity:important against gcc-6.  Unless the
policy has changed, "has a major effect on the usability of a package, without
rendering it completely unusable to everyone" still warrants that.  And
kernel development (including bisects) has, until now, been consdered
a normal use of gcc.

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

[Sebastian Andrzej Siewior]

On 2016-11-04 16:10:48 [+0000], Al Viro wrote:
> And I don't see any way around severity:important against gcc-6.  Unless the
> policy has changed, "has a major effect on the usability of a package, without
> rendering it completely unusable to everyone" still warrants that.  And
> kernel development (including bisects) has, until now, been consdered
> a normal use of gcc.

point. Granted. We had the same thing a while back when `GNU make' update
led to an build error due a rule in kernel's Makefile.

Sebastian

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

[Adam Borowski]

On Fri, Nov 04, 2016 at 04:58:55PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-04 15:54:27 [+0000], Al Viro wrote:
> > Christoph, would you mind rereading what I posted upthread?  I *am* aware of
> > that clusterfuck, including the Balint's charming games with the reassignments,
> > etc.  Directly affected by the whole mess, actually.
> 
> Al, I am re-doing the patch with a runtime check for -fno-PIE and
> tagging it stable and looking after Ben's fstack protector thingy.
> This should allow you to compile maintained stable kernels but it won't
> allow you to bisect to prior versions.
> I don't see any other way around it.

As you guys don't want Gentooish attempts to check if gcc is compiling the
kernel, what about making/requesting a wrapper that calls gcc with the
appropriate options (-fno-PIE and whatever is needed for fstack protector)?

This would require manually appending CC=the-wrapper to make but would allow
bisects.  And come on, any solution with no bisects is rather ridiculous.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[Sven Joachim]

On 2016-11-02 18:20 +0100, Sebastian Andrzej Siewior wrote:

> Debian Woody is pre-gcc3.2 and Sarge ships 3.3 gcc. I tried to compile
> v4.8.6 on Sarge failed due to binutils:
> |arch/x86/entry/entry_32.S: Assembler messages:
> |arch/x86/entry/entry_32.S:379: Error: invalid character '"' in operand 1
> |arch/x86/entry/entry_32.S:454: Error: too many positional arguments
> |arch/x86/entry/entry_32.S:580: Error: too many positional arguments
> |arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit base/index expression
>
> among other errors. Sarge comes with GNU ld version 2.15 with is not
> recent enough. I don't see those errors on Etch which ships version 2.17
> and therefore I raise the limit to 2.17.

I can confirm that binutils 2.16 is not recent enough either, while 2.17
works.

> gcc is a different story. 3.3 It throws a lot of warnings
> |include/linux/irq.h:402: warning: parameter has incomplete type
> |include/linux/irq.h:403: warning: parameter has incomplete type
> |drivers/gpu/drm/i915/i915_gem_gtt.h:312: warning: parameter has incomplete type
>
> during the compile and fails then with
> | cc1: error: unrecognized option `-Wno-override-init'
>
> or later with
>
> |lib/lzo/lzo1x_compress.c: In function `lzo1x_1_do_compress':
> |lib/lzo/lzo1x_compress.c:132: error: implicit declaration of function `__builtin_ctz'
>
> Etch (with gcc v4.1.2) gets to compile the kernel without plenty of
> warnings and it also chokes on Wno-override-init but that one could be
> easily fixed if we want to keep v4.1 as the minimum.
> So I think raising the bar to gcc v4.1 isn't that bad given that the
> last release of gcc 4.1 was on February 13, 2007.

For the record, the -Wno-override-init problem has already been fixed in
4.9-rc3 by commit a2209b742e6 ("x86/build: Fix build with older GCC
versions").

Cheers,
       Sven

> diff --git a/Documentation/Changes b/Documentation/Changes
> index 22797a15dc24..14e65b445707 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -29,9 +29,9 @@ you probably needn't concern yourself with isdn4k-utils.
>  ====================== ===============  ========================================
>          Program        Minimal version       Command to check the version
>  ====================== ===============  ========================================
> -GNU C                  3.2              gcc --version
> +GNU C                  4.1              gcc --version
>  GNU make               3.80             make --version
> -binutils               2.12             ld -v
> +binutils               2.17             ld -v
>  util-linux             2.10o            fdformat --version
>  module-init-tools      0.9.10           depmod -V
>  e2fsprogs              1.41.4           e2fsck -V
> -- 
> 2.10.2

Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[Borislav Petkov]

On Wed, Nov 02, 2016 at 06:20:57PM +0100, Sebastian Andrzej Siewior wrote:
> Etch (with gcc v4.1.2) gets to compile the kernel without plenty of
> warnings and it also chokes on Wno-override-init but that one could be
> easily fixed if we want to keep v4.1 as the minimum.
> So I think raising the bar to gcc v4.1 isn't that bad given that the
> last release of gcc 4.1 was on February 13, 2007.

You'd need to adjust

#if GCC_VERSION < 30200

in include/linux/compiler-gcc.h.

> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  Documentation/Changes | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/Changes b/Documentation/Changes
> index 22797a15dc24..14e65b445707 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -29,9 +29,9 @@ you probably needn't concern yourself with isdn4k-utils.
>  ====================== ===============  ========================================
>          Program        Minimal version       Command to check the version
>  ====================== ===============  ========================================
> -GNU C                  3.2              gcc --version
> +GNU C                  4.1              gcc --version
>  GNU make               3.80             make --version
> -binutils               2.12             ld -v
> +binutils               2.17             ld -v

That probably would be a good thing as 2.16 is the Binutils Version from
Hell.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.