* [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils @ 2016-11-02 17:20 Sebastian Andrzej Siewior 2016-11-02 17:20 ` [PATCH 2/2] kbuild: add -fno-PIE Sebastian Andrzej Siewior ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Sebastian Andrzej Siewior @ 2016-11-02 17:20 UTC (permalink / raw) To: linux-kernel Cc: Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, ben, Sebastian Andrzej Siewior, Jonathan Corbet, linux-doc, Andrew Morton 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/2] kbuild: add -fno-PIE 2016-11-02 17:20 [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils Sebastian Andrzej Siewior @ 2016-11-02 17:20 ` Sebastian Andrzej Siewior 2016-11-03 22:50 ` Ben Hutchings 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 2 siblings, 1 reply; 18+ messages in thread From: Sebastian Andrzej Siewior @ 2016-11-02 17:20 UTC (permalink / raw) To: linux-kernel Cc: Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, ben, 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 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 0 siblings, 1 reply; 18+ messages in thread From: Ben Hutchings @ 2016-11-03 22:50 UTC (permalink / raw) To: Sebastian Andrzej Siewior, linux-kernel Cc: Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-03 22:50 ` Ben Hutchings @ 2016-11-04 1:08 ` Al Viro 2016-11-04 11:37 ` Austin S. Hemmelgarn 0 siblings, 1 reply; 18+ messages in thread From: Al Viro @ 2016-11-04 1:08 UTC (permalink / raw) To: Ben Hutchings Cc: Sebastian Andrzej Siewior, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 1:08 ` Al Viro @ 2016-11-04 11:37 ` Austin S. Hemmelgarn 2016-11-04 14:24 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 18+ messages in thread From: Austin S. Hemmelgarn @ 2016-11-04 11:37 UTC (permalink / raw) To: Al Viro, Ben Hutchings Cc: Sebastian Andrzej Siewior, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild 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). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 11:37 ` Austin S. Hemmelgarn @ 2016-11-04 14:24 ` Sebastian Andrzej Siewior 2016-11-04 14:39 ` Markus Trippelsdorf ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Sebastian Andrzej Siewior @ 2016-11-04 14:24 UTC (permalink / raw) To: Austin S. Hemmelgarn, Al Viro Cc: Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 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 2016-11-04 15:18 ` Al Viro 2 siblings, 1 reply; 18+ messages in thread From: Markus Trippelsdorf @ 2016-11-04 14:39 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Austin S. Hemmelgarn, Al Viro, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 14:39 ` Markus Trippelsdorf @ 2016-11-04 14:55 ` Austin S. Hemmelgarn 0 siblings, 0 replies; 18+ messages in thread From: Austin S. Hemmelgarn @ 2016-11-04 14:55 UTC (permalink / raw) To: Markus Trippelsdorf, Sebastian Andrzej Siewior Cc: Al Viro, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 14:24 ` Sebastian Andrzej Siewior 2016-11-04 14:39 ` Markus Trippelsdorf @ 2016-11-04 14:47 ` Austin S. Hemmelgarn 2016-11-04 15:18 ` Al Viro 2 siblings, 0 replies; 18+ messages in thread From: Austin S. Hemmelgarn @ 2016-11-04 14:47 UTC (permalink / raw) To: Sebastian Andrzej Siewior, Al Viro Cc: Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 14:24 ` Sebastian Andrzej Siewior 2016-11-04 14:39 ` Markus Trippelsdorf 2016-11-04 14:47 ` Austin S. Hemmelgarn @ 2016-11-04 15:18 ` Al Viro 2016-11-04 15:22 ` Christoph Hellwig 2 siblings, 1 reply; 18+ messages in thread From: Al Viro @ 2016-11-04 15:18 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 15:18 ` Al Viro @ 2016-11-04 15:22 ` Christoph Hellwig 2016-11-04 15:54 ` Al Viro 0 siblings, 1 reply; 18+ messages in thread From: Christoph Hellwig @ 2016-11-04 15:22 UTC (permalink / raw) To: Al Viro Cc: Sebastian Andrzej Siewior, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 15:22 ` Christoph Hellwig @ 2016-11-04 15:54 ` Al Viro 2016-11-04 15:58 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 18+ messages in thread From: Al Viro @ 2016-11-04 15:54 UTC (permalink / raw) To: Christoph Hellwig Cc: Sebastian Andrzej Siewior, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 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:25 ` Adam Borowski 0 siblings, 2 replies; 18+ messages in thread From: Sebastian Andrzej Siewior @ 2016-11-04 15:58 UTC (permalink / raw) To: Al Viro Cc: Christoph Hellwig, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 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 1 sibling, 1 reply; 18+ messages in thread From: Al Viro @ 2016-11-04 16:10 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Christoph Hellwig, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 16:10 ` Al Viro @ 2016-11-04 16:17 ` Sebastian Andrzej Siewior 0 siblings, 0 replies; 18+ messages in thread From: Sebastian Andrzej Siewior @ 2016-11-04 16:17 UTC (permalink / raw) To: Al Viro Cc: Christoph Hellwig, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, doko 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] kbuild: add -fno-PIE 2016-11-04 15:58 ` Sebastian Andrzej Siewior 2016-11-04 16:10 ` Al Viro @ 2016-11-04 16:25 ` Adam Borowski 1 sibling, 0 replies; 18+ messages in thread From: Adam Borowski @ 2016-11-04 16:25 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Al Viro, Christoph Hellwig, Austin S. Hemmelgarn, Ben Hutchings, linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Michal Marek, linux-kbuild, doko 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils 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-02 18:52 ` Sven Joachim 2016-11-02 19:55 ` Borislav Petkov 2 siblings, 0 replies; 18+ messages in thread From: Sven Joachim @ 2016-11-02 18:52 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: linux-kernel, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, ben, Jonathan Corbet, linux-doc, Andrew Morton 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils 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-02 18:52 ` [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils Sven Joachim @ 2016-11-02 19:55 ` Borislav Petkov 2 siblings, 0 replies; 18+ messages in thread From: Borislav Petkov @ 2016-11-02 19:55 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: linux-kernel, Sven Joachim, Tomas Janousek, Joe Perches, Adam Borowski, Michal Marek, linux-kbuild, ben, Jonathan Corbet, linux-doc, Andrew Morton, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-11-04 16:25 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).