| Message ID | 20161102172058.13641-2-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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). -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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!
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
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(-)