Message ID | alpine.DEB.2.20.99.1701040957380.31470@trent.utfs.org (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On Wed, 4 Jan 2017, Christian Kujau wrote: > So, would the following be sufficient? It compiles, but I haven't had a > chance to boot yet. > So, with -fno-stack-protector my GCC 4.9.2 compiles with CC_STACKPROTECTOR_STRONG=y but panics during boot: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c069278c CPU: 0 PIP: 591 Comm: systemd Tainted: G W 4.10.0-rc3-dirty Call Trace: [ee965bb0] [c0693f5c] panic+0x120/0x274 (unreliable) [ee965c10] [c002c568] print_tainted+0x0/0xcc [ee965c20] [c069278c] schedule_timeout+0x25c/0x280 [ee965c80] [c068cc30] io_schedule_timeout+0x90/0xf4 [ee965ca0] [c00ac870] wait_on_page_bit_killable+0x1Oc/0x170 [ee965cf0] [c00ad240] __lock_page_or_retry+0xd4/0x12c [ee965d10] [c00ad708] filemap_fault+0x470/0x5b0 [ee965d60] [c00d07c8] __do_fault+0x2c/0x90 [ee965e40] [c00d4104] handle_mm__fault+0x7c0/0x9cc [ee965e00] [c0015a6c] do_page_fault+0x2ec,0x5b4 [ee965e40] [c0011660] handle_page_fault+0xc/0x80 --- interrupt: 301 at do_page_fault+0x394/0x5b4 LR = do_page_fault+0x378,0x5b4 [ee965f00] [c0015c04] do_page_fault+0x484/0x5b4 (unreliable) [ee965f40] [c0011660] handle_page_fault+0xc/0x80 --- interrupt: 401 at 0x2074d000 LR = 0x207cff0 Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? Thanks, Christian. > > diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile > index 1eb7b45..c7dcab9 100644 > --- a/arch/powerpc/platforms/powermac/Makefile > +++ b/arch/powerpc/platforms/powermac/Makefile > @@ -1,4 +1,4 @@ > -CFLAGS_bootx_init.o += -fPIC > +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > > > Thanks, > Christian. > -- > BOFH excuse #156: > > Zombie processes haunting the computer >
On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote: > So, with -fno-stack-protector my GCC 4.9.2 compiles with > CC_STACKPROTECTOR_STRONG=y but panics during boot: How can it make any sense to have -fno-stack-protector and CC_STACKPROTECTOR_STRONG=y at the same time ? Ben.
Le 10/01/2017 à 03:11, Christian Kujau a écrit : > On Wed, 4 Jan 2017, Christian Kujau wrote: >> So, would the following be sufficient? It compiles, but I haven't had a >> chance to boot yet. >> > > So, with -fno-stack-protector my GCC 4.9.2 compiles with > CC_STACKPROTECTOR_STRONG=y but panics during boot: > > > > Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? Indeed, the latest versions of GCC don't use anymore the global variable __stack_chk_guard as canary value, but a value stored at -0x7008(r2). This is not compatible with the current implementation of the kernel with uses r2 as a pointeur to current task struct. So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC with modern versions of GCC. Christophe > > Thanks, > Christian. > >> >> diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile >> index 1eb7b45..c7dcab9 100644 >> --- a/arch/powerpc/platforms/powermac/Makefile >> +++ b/arch/powerpc/platforms/powermac/Makefile >> @@ -1,4 +1,4 @@ >> -CFLAGS_bootx_init.o += -fPIC >> +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector >> >> ifdef CONFIG_FUNCTION_TRACER >> # Do not trace early boot code >> >> >> Thanks, >> Christian. >> -- >> BOFH excuse #156: >> >> Zombie processes haunting the computer >> >
On Mon, 9 Jan 2017, Benjamin Herrenschmidt wrote: > On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote: > > So, with -fno-stack-protector my GCC 4.9.2 compiles with > > CC_STACKPROTECTOR_STRONG=y but panics during boot: > > How can it make any sense to have -fno-stack-protector and > CC_STACKPROTECTOR_STRONG=y at the same time ? I've set -fno-stack-protector only for bootx_init.c, as laid out in the diff I posted. This way the kernel at least compiled. Thanks, Christian.
On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote: > >Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? > > Indeed, the latest versions of GCC don't use anymore the global variable > __stack_chk_guard as canary value, but a value stored at -0x7008(r2). > This is not compatible with the current implementation of the kernel > with uses r2 as a pointeur to current task struct. > So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC > with modern versions of GCC. I still wonder what changed. Nothing relevant has changed for ten years or whatever as far as I see; unless it is just the -fstack-protector-strong that makes it fail now. Curious. Segher
Le 11/01/2017 à 23:54, Segher Boessenkool a écrit : > On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote: >>> Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? >> >> Indeed, the latest versions of GCC don't use anymore the global variable >> __stack_chk_guard as canary value, but a value stored at -0x7008(r2). >> This is not compatible with the current implementation of the kernel >> with uses r2 as a pointeur to current task struct. >> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC >> with modern versions of GCC. > > I still wonder what changed. Nothing relevant has changed for ten years > or whatever as far as I see; unless it is just the -fstack-protector-strong > that makes it fail now. Curious. > Yes, looks like it was changed from global to TLS in 2005 on powerpc. Indeed when I implemented STACKPROTECTOR in Kernel on ppc I copied/pasted it from ARM which is (still?) using the global __stack_chk_guard, and at first it worked quite well on my powerpc. x86 has the following option on GCC. Couldn't we have it on powerpc too ? -mstack-protector-guard=guard Generate stack protection code using canary at guard. Supported locations are ‘ global ’ for global canary or ‘ tls ’ for per-thread canary in the TLS block (the default). This option has effect only when ‘-fstack-protector’ or ‘-fstack-protector-all’ is specified. Christophe
Le 12/01/2017 à 08:52, Christophe LEROY a écrit : > > > Le 11/01/2017 à 23:54, Segher Boessenkool a écrit : >> On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote: >>>> Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ? >>> >>> Indeed, the latest versions of GCC don't use anymore the global variable >>> __stack_chk_guard as canary value, but a value stored at -0x7008(r2). >>> This is not compatible with the current implementation of the kernel >>> with uses r2 as a pointeur to current task struct. >>> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC >>> with modern versions of GCC. >> >> I still wonder what changed. Nothing relevant has changed for ten years >> or whatever as far as I see; unless it is just the >> -fstack-protector-strong >> that makes it fail now. Curious. >> > > Yes, looks like it was changed from global to TLS in 2005 on powerpc. > Indeed when I implemented STACKPROTECTOR in Kernel on ppc I > copied/pasted it from ARM which is (still?) using the global > __stack_chk_guard, and at first it worked quite well on my powerpc. > > x86 has the following option on GCC. Couldn't we have it on powerpc too ? > > -mstack-protector-guard=guard > Generate stack protection code using canary at > guard. Supported locations are ‘ global ’ for global canary or ‘ tls > ’ for per-thread canary in the TLS block (the default). This option > has effect only when ‘-fstack-protector’ or ‘-fstack-protector-all’ > is specified. > Finally, it looks like it is not so easy. I have three instances of GCC: * 4.4.4, home built * 4.6.3, from https://www.kernel.org/pub/tools/crosstool/ * 4.8.3, home built The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use -28680(r2) Is it dependent on the way GCC is built ? Then do we have a way to know, when we compile, which method GCC will use ? See details below for each of the 3 GCC versions. Christophe Using built-in specs. Target: ppc-linux Configured with: /root/cldk/gcc-4.4.4/configure --target=ppc-linux --with-headers=yes --with-cpu=860 --prefix=/opt/cldk --bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin --libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share --sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib --includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include --infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man --enable-languages=c,c++ Thread model: posix gcc version 4.4.4 (GCC) 0000007c <name_to_dev_t>: 7c: 7c 08 02 a6 mflr r0 80: 94 21 ff a0 stwu r1,-96(r1) 84: 3c 80 00 00 lis r4,0 86: R_PPC_ADDR16_HA .rodata.str1.4+0x1bc 88: 93 c1 00 58 stw r30,88(r1) 8c: 93 e1 00 5c stw r31,92(r1) 90: 90 01 00 64 stw r0,100(r1) 94: 93 81 00 50 stw r28,80(r1) 98: 93 a1 00 54 stw r29,84(r1) 9c: 38 84 01 bc addi r4,r4,444 9e: R_PPC_ADDR16_LO .rodata.str1.4+0x1bc a0: 38 a0 00 09 li r5,9 a4: 80 02 8f f8 lwz r0,-28680(r2) a8: 90 01 00 4c stw r0,76(r1) [...] fc: 80 01 00 4c lwz r0,76(r1) 100: 81 22 8f f8 lwz r9,-28680(r2) 104: 7c 00 4a 79 xor. r0,r0,r9 108: 39 20 00 00 li r9,0 10c: 7f a3 eb 78 mr r3,r29 110: 40 82 03 88 bne- 498 <name_to_dev_t+0x41c> [...] 498: 48 00 00 01 bl 498 <name_to_dev_t+0x41c> 498: R_PPC_REL24 __stack_chk_fail Using built-in specs. COLLECT_GCC=powerpc64-linux-gcc COLLECT_LTO_WRAPPER=/opt/gcc-4.6.3-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/4.6.3/lto-wrapper Target: powerpc64-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc64-linux --host=i686-linux-gnu --build=i686-linux-gnu --enable-targets=all --prefix=/opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys-i686 --with-gmp=/home/tony/buildall/src/sys-i686 --disable-bootstrap --disable-libquadmath Thread model: single gcc version 4.6.3 (GCC) 000000c0 <name_to_dev_t>: c0: 94 21 ff a0 stwu r1,-96(r1) c4: 7c 08 02 a6 mflr r0 c8: 3c 80 00 00 lis r4,0 ca: R_PPC_ADDR16_HA .rodata.str1.4+0x50 cc: 38 a0 00 09 li r5,9 d0: 38 84 00 50 addi r4,r4,80 d2: R_PPC_ADDR16_LO .rodata.str1.4+0x50 d4: bf 81 00 50 stmw r28,80(r1) d8: 3f e0 00 00 lis r31,0 da: R_PPC_ADDR16_HA __stack_chk_guard dc: 7c 7e 1b 78 mr r30,r3 e0: 90 01 00 64 stw r0,100(r1) e4: 3b ff 00 00 addi r31,r31,0 e6: R_PPC_ADDR16_LO __stack_chk_guard e8: 80 1f 00 00 lwz r0,0(r31) ec: 90 01 00 4c stw r0,76(r1) [...] 13c: 81 21 00 4c lwz r9,76(r1) 140: 80 1f 00 00 lwz r0,0(r31) 144: 7d 29 02 79 xor. r9,r9,r0 148: 38 00 00 00 li r0,0 14c: 7f 83 e3 78 mr r3,r28 150: 40 82 03 68 bne- 4b8 <name_to_dev_t+0x3f8> [...] 4b8: 48 00 00 01 bl 4b8 <name_to_dev_t+0x3f8> 4b8: R_PPC_REL24 __stack_chk_fail Using built-in specs. COLLECT_GCC=ppc-linux-gcc COLLECT_LTO_WRAPPER=/opt/cldk/libexec/gcc/ppc-linux/4.8.3/lto-wrapper Target: ppc-linux Configured with: /root/cldk/gcc-4.8.3/configure --target=ppc-linux --with-headers=yes --with-cpu=860 --prefix=/opt/cldk --bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin --libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share --sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib --includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include --infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man --enable-languages=c,c++ Thread model: posix gcc version 4.8.3 (GCC) 000000b0 <name_to_dev_t>: b0: 7c 08 02 a6 mflr r0 b4: 94 21 ff a0 stwu r1,-96(r1) b8: 3c 80 00 00 lis r4,0 ba: R_PPC_ADDR16_HA .rodata.str1.4+0x50 bc: bf a1 00 54 stmw r29,84(r1) c0: 90 01 00 64 stw r0,100(r1) c4: 38 84 00 00 addi r4,r4,0 c6: R_PPC_ADDR16_LO .rodata.str1.4+0x50 c8: 38 a0 00 09 li r5,9 cc: 7c 7f 1b 78 mr r31,r3 d0: 81 22 8f f8 lwz r9,-28680(r2) d4: 91 21 00 4c stw r9,76(r1) [...] 124: 81 41 00 4c lwz r10,76(r1) 128: 81 22 8f f8 lwz r9,-28680(r2) 12c: 7d 4a 4a 79 xor. r10,r10,r9 130: 39 20 00 00 li r9,0 134: 40 82 03 70 bne 4a4 <name_to_dev_t+0x3f4> [...] 4a4: 48 00 00 01 bl 4a4 <name_to_dev_t+0x3f4> 4a4: R_PPC_REL24 __stack_chk_fail
On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote: > The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use > -28680(r2) > > Is it dependent on the way GCC is built ? Then do we have a way to > know, > when we compile, which method GCC will use ? > > See details below for each of the 3 GCC versions. I think it depends if you built it along with glibc (so it can produce userspace binaries) or not. Cheers, Ben.
On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote: > On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote: > > The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use > > -28680(r2) > > > > Is it dependent on the way GCC is built ? Then do we have a way to > > know, > > when we compile, which method GCC will use ? > > > > See details below for each of the 3 GCC versions. > > I think it depends if you built it along with glibc (so it can produce > userspace binaries) or not. Right. Tony's compilers are built using a (modified version of) buildall, and buildall goes out of its way to build without libc whatsoever, even if the configuration (powerpc64-linux, for example) expects one. Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally be true for glibc >= 2.4), and that is all. Mystery solved. Thanks! Segher
Le 12/01/2017 à 19:07, Segher Boessenkool a écrit : > On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote: >> On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote: >>> The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use >>> -28680(r2) >>> >>> Is it dependent on the way GCC is built ? Then do we have a way to >>> know, >>> when we compile, which method GCC will use ? >>> >>> See details below for each of the 3 GCC versions. >> >> I think it depends if you built it along with glibc (so it can produce >> userspace binaries) or not. > > Right. Tony's compilers are built using a (modified version of) buildall, > and buildall goes out of its way to build without libc whatsoever, even > if the configuration (powerpc64-linux, for example) expects one. > > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks! > Is there a way to know during compilation how the compiler will behave, in order to select the correct method ? I have drafted a new approach in the kernel that uses -0x7008(r2) instead of the global __stack_chk_guard, but how can I select the proper approach during kernel compilation in line with the selected GCC ? Christophe
From: Christophe LEROY > Sent: 13 January 2017 12:15 ... > > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally > > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks! > > > > Is there a way to know during compilation how the compiler will behave, > in order to select the correct method ? > > I have drafted a new approach in the kernel that uses -0x7008(r2) > instead of the global __stack_chk_guard, but how can I select the proper > approach during kernel compilation in line with the selected GCC ? Worse, how can you ensure that loadable modules are compiled with the same option as the rest of the kernel. David
diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 1eb7b45..c7dcab9 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -1,4 +1,4 @@ -CFLAGS_bootx_init.o += -fPIC +CFLAGS_bootx_init.o += -fPIC -fno-stack-protector ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code