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 <[email protected]>
Cc: [email protected]
Cc: Andrew Morton <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
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
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 <[email protected]>
---
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
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
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 <[email protected]>
> Cc: [email protected]
> Cc: Andrew Morton <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> 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.
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.
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.
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).
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
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
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.
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.
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.
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
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.
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
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.
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
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.