RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[David Laight]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Segher Boessenkool]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Benjamin Herrenschmidt]

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.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

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)

007c :
  7c:   7c 08 02 a6 mflrr0
  80:   94 21 ff a0 stwur1,-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 addir4,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 

[...]

 498:   48 00 00 01 bl  498 
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)

00c0 :
  c0:   94 21 ff a0 stwur1,-96(r1)
  c4:   7c 08 02 a6 mflrr0
  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 addir4,r4,80
d2: R_PPC_ADDR16_LO .rodata.str1.4+0x50
  d4:   bf 81 00 50 stmwr28,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 addir31,r31,0
e6: R_PPC_ADDR16_LO __stack_chk_guard
  e8:   80 1f 00 00 lwz 

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Segher Boessenkool]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

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.
-- 
BOFH excuse #423:

It's not RFC-822 compliant.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

Le 10/01/2017 à 05:32, Benjamin Herrenschmidt a écrit :

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 ?



As far as I understand, Christian means no stack protector on file 
bootx_init.o, see below


Christophe

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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Benjamin Herrenschmidt]

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.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

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
> 

-- 
BOFH excuse #450:

Terrorists crashed an airplane into the server room, have to remove /bin/laden. 
(rm -rf /bin/laden)

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Using GCC 5.4.0, I don't have that issue. bootx_init.o only contains reference
> to __stack_chk_fail

FWIW, building with a GCC 5.2 crosscompiler succeeds (with 
CONFIG_CC_STACKPROTECTOR_STRONG=y), but I don't know if it will boot 
though, see my other mail in this thread:

  https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/152623.html

So, would the following be sufficient? It compiles, but I haven't had a 
chance to boot yet.


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

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

On Wed, 4 Jan 2017, Christophe LEROY wrote:
> Looking a bit over internet, some people have reported having encountered that
> issue due to old object files not properly cleaned.
> Have you tried a 'make clean' or 'distclean' ?

I'm compiling with O=$DIR and I've deleted the entire $DIR before 
compilation. So no, old object files is not the issue here.

Christian.
-- 
BOFH excuse #105:

UPS interrupted the server's power

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Segher Boessenkool]

On Wed, Jan 04, 2017 at 09:23:47AM +0100, Christophe LEROY wrote:
> >The way gcc implements the stack protector has some serious
> >incompatibilities with the way the Linux kernel uses r13, I wouldn't
> >even try until we sort that out...
> 
> Yes indeed, it looks like recent versions of GCC don't use anymore the 
> global __stack_chk_guard variable but a hard coded offset relative to r2 
> or r13:
> 
> On 32 bits, it uses -7008(r2)
> On 64 bits, it uses -7010(r13)

This is https://gcc.gnu.org/PR78875 .  It should have been this way since
forever; if it really wasn't, it is unclear why not.

Either way, we (i.e. GCC) will add some compiler option to make this work
for the kernel.  It will be part of 7 and we'll probably backport it to
6.4 and 5.5 .

For bootx_init.c, this probably should be compiled with -fno-stack-protector
just like all the other boot time stuff.


Segher

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

Le 03/01/2017 à 23:50, Benjamin Herrenschmidt a écrit :

On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:

Hi,

when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
linker fails with:


The way gcc implements the stack protector has some serious
incompatibilities with the way the Linux kernel uses r13, I wouldn't
even try until we sort that out...


Yes indeed, it looks like recent versions of GCC don't use anymore the 
global __stack_chk_guard variable but a hard coded offset relative to r2 
or r13:


On 32 bits, it uses -7008(r2)
On 64 bits, it uses -7010(r13)

On 32 bits, r2 points to current struct, which contains the stack_canary 
value for the task. I have tried to alter get_current() in order to 
define it as an offset to r2 so that current->stack_canary is at 
-7008(r2), but I end up with circular cross references in header files 
and still have task_struct undefined when get_current() needs it to 
calculate offset of stack_canary within the structure.


When CONFIG_CC_STACKPROTECTOR is active, would it be feasible to get the 
pointer to current from the stack using the thread_info instead of using 
r2 reg ? That way we could keep r2 to point to current->stack_canary + 
0x7008


Christophe



Cheers,
Ben.



+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T
./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o
arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o
arch/powerpc/kernel/prom_init.o init/built-in.o --start-group
usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-
in.o
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
ipc/built-in.o security/built-in.o crypto/built-in.o block/built-
in.o
lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
arch/powerpc/platforms/built-in.o: In function `bootx_printf':
/usr/local/src/linux-
git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined
reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function
`bootx_add_display_props':
/usr/local/src/linux-
git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined
reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function
`bootx_scan_dt_build_struct':
/usr/local/src/linux-
git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined
reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_init':
/usr/local/src/linux-
git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined
reference to `__stack_chk_fail_local'
/usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol
`__stack_chk_fail_local' isn't defined
/usr/bin/ld.bfd.real: final link failed: Bad value



$ ld --version | head -1
GNU ld (GNU Binutils for Debian) 2.25

$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2


I'm regularly compiling userspace programs with -fstack-protector
w/o
problems. I suspect it's either
6533b7c16ee5712041b4e324100550e02a9a5dda
("powerpc: Initial stack protector (-fstack-protector) support") or
902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the
stack
protector canary value per task") or both but I haven't started the
bisection yet.

Any other ideas?

Thanks,
Christian.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christophe LEROY]

Le 03/01/2017 à 16:25, Christian Kujau a écrit :

Hi,

when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the
linker fails with:


+ ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T
./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o
arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o
arch/powerpc/kernel/prom_init.o init/built-in.o --start-group
usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o
kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o
ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
arch/powerpc/platforms/built-in.o: In function `bootx_printf':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function
`bootx_scan_dt_build_struct':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: 
undefined reference to `__stack_chk_fail_local'
arch/powerpc/platforms/built-in.o: In function `bootx_init':
/usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: 
undefined reference to `__stack_chk_fail_local'
/usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' 
isn't defined
/usr/bin/ld.bfd.real: final link failed: Bad value



$ ld --version | head -1
GNU ld (GNU Binutils for Debian) 2.25

$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2


I'm regularly compiling userspace programs with -fstack-protector w/o
problems. I suspect it's either 6533b7c16ee5712041b4e324100550e02a9a5dda
("powerpc: Initial stack protector (-fstack-protector) support") or
902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the stack
protector canary value per task") or both but I haven't started the
bisection yet.

Any other ideas?

Thanks,
Christian.



Using GCC 5.4.0, I don't have that issue. bootx_init.o only contains 
reference to __stack_chk_fail


Looking a bit over internet, some people have reported having 
encountered that issue due to old object files not properly cleaned.


Have you tried a 'make clean' or 'distclean' ?

Christophe

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

On Wed, 4 Jan 2017, Benjamin Herrenschmidt wrote:
> On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
> > Hi,
> > 
> > when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the 
> > linker fails with:
> 
> The way gcc implements the stack protector has some serious
> incompatibilities with the way the Linux kernel uses r13, I wouldn't
> even try until we sort that out...

Yeah, I noticed. While _compilation_ succeeded with 
CONFIG_CC_STACKPROTECTOR_REGULAR=y, the kernel panicked during boot with:

Kernel panic - not syning: stack-protector: Kernel stack is corrupted in: 
c0103894
CPU: 0 PID: 586 Comm: systemd Tainted: G  W 4.10.0-rc2 #3
Call Trace:
[ee949ca0] [c067d6cc] panic+0x114/0x268 (unreliable)
[ee949d00] [c002be80] print_tainted+0x0/0xcc
[ee949d10] [c0103894] path_openat+0x1014/0x1050
[ee949df0] [c01048dc] do_filp_open+0xac/0xfc
[ee949ea0] [c00f994c] do_open_execat+0x64/0x1bc
[ee949ee0] [c00fb0f8] do_execveat_common+0x24c/0x774
[ee949f30] [c00fb650] do_execve+0x30/0x40
[ee949f40] [c0010db0] ret_from_syscall+0x0/0x38
--- interrupt: c01 at 0x20403618
LR = 0x204037ac


(written down manually, hopefully w/o typos).

I'll disable the stack protector on this powerpc (G4) machine for now.

Thanks,
Christian.

> 
> Cheers,
> Ben.
> > 
> > 
> > + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T 
> > ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o 
> > arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o 
> > arch/powerpc/kernel/prom_init.o init/built-in.o --start-group 
> > usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-
> > in.o 
> > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o 
> > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o 
> > arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o 
> > kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o 
> > ipc/built-in.o security/built-in.o crypto/built-in.o block/built-
> > in.o 
> > lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o 
> > firmware/built-in.o net/built-in.o virt/built-in.o --end-group
> > arch/powerpc/platforms/built-in.o: In function `bootx_printf':
> > /usr/local/src/linux-
> > git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined
> > reference to `__stack_chk_fail_local'
> > arch/powerpc/platforms/built-in.o: In function
> > `bootx_add_display_props':
> > /usr/local/src/linux-
> > git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined
> > reference to `__stack_chk_fail_local'
> > arch/powerpc/platforms/built-in.o: In function 
> > `bootx_scan_dt_build_struct':
> > /usr/local/src/linux-
> > git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined
> > reference to `__stack_chk_fail_local'
> > arch/powerpc/platforms/built-in.o: In function `bootx_init':
> > /usr/local/src/linux-
> > git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined
> > reference to `__stack_chk_fail_local'
> > /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol
> > `__stack_chk_fail_local' isn't defined
> > /usr/bin/ld.bfd.real: final link failed: Bad value
> > 
> > 
> > 
> > $ ld --version | head -1
> > GNU ld (GNU Binutils for Debian) 2.25
> > 
> > $ gcc --version | head -1
> > gcc-4.9.real (Debian 4.9.2-10) 4.9.2
> > 
> > 
> > I'm regularly compiling userspace programs with -fstack-protector
> > w/o 
> > problems. I suspect it's either
> > 6533b7c16ee5712041b4e324100550e02a9a5dda 
> > ("powerpc: Initial stack protector (-fstack-protector) support") or 
> > 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the
> > stack 
> > protector canary value per task") or both but I haven't started the 
> > bisection yet.
> > 
> > Any other ideas?
> > 
> > Thanks,
> > Christian.
> 
> 

-- 
BOFH excuse #111:

The salesman drove over the CPU board.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Benjamin Herrenschmidt]

On Tue, 2017-01-03 at 07:25 -0800, Christian Kujau wrote:
> Hi,
> 
> when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the 
> linker fails with:

The way gcc implements the stack protector has some serious
incompatibilities with the way the Linux kernel uses r13, I wouldn't
even try until we sort that out...

Cheers,
Ben.
> 
> 
> + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T 
> ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o 
> arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o 
> arch/powerpc/kernel/prom_init.o init/built-in.o --start-group 
> usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-
> in.o 
> arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o 
> arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o 
> arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o 
> kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o 
> ipc/built-in.o security/built-in.o crypto/built-in.o block/built-
> in.o 
> lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o 
> firmware/built-in.o net/built-in.o virt/built-in.o --end-group
> arch/powerpc/platforms/built-in.o: In function `bootx_printf':
> /usr/local/src/linux-
> git/arch/powerpc/platforms/powermac/bootx_init.c:88: undefined
> reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function
> `bootx_add_display_props':
> /usr/local/src/linux-
> git/arch/powerpc/platforms/powermac/bootx_init.c:211: undefined
> reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function 
> `bootx_scan_dt_build_struct':
> /usr/local/src/linux-
> git/arch/powerpc/platforms/powermac/bootx_init.c:350: undefined
> reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function `bootx_init':
> /usr/local/src/linux-
> git/arch/powerpc/platforms/powermac/bootx_init.c:596: undefined
> reference to `__stack_chk_fail_local'
> /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol
> `__stack_chk_fail_local' isn't defined
> /usr/bin/ld.bfd.real: final link failed: Bad value
> 
> 
> 
> $ ld --version | head -1
> GNU ld (GNU Binutils for Debian) 2.25
> 
> $ gcc --version | head -1
> gcc-4.9.real (Debian 4.9.2-10) 4.9.2
> 
> 
> I'm regularly compiling userspace programs with -fstack-protector
> w/o 
> problems. I suspect it's either
> 6533b7c16ee5712041b4e324100550e02a9a5dda 
> ("powerpc: Initial stack protector (-fstack-protector) support") or 
> 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the
> stack 
> protector canary value per task") or both but I haven't started the 
> bisection yet.
> 
> Any other ideas?
> 
> Thanks,
> Christian.

Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

[Christian Kujau]

On Tue, 3 Jan 2017, Christian Kujau wrote:
> when compiling v4.10-rc2 with CONFIG_CC_STACKPROTECTOR_STRONG=y, the 
> linker fails with:

FWIW, compiling with CONFIG_CC_STACKPROTECTOR_REGULAR=y instead works 
just fine.

C.

> 
> 
> + ld -EB -m elf32ppc -Bstatic --build-id -X -o .tmp_vmlinux1 -T 
> ./arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_32.o 
> arch/powerpc/kernel/fpu.o arch/powerpc/kernel/vector.o 
> arch/powerpc/kernel/prom_init.o init/built-in.o --start-group 
> usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o 
> arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o 
> arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o 
> arch/powerpc/crypto/built-in.o arch/powerpc/net/built-in.o 
> kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o 
> ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o 
> lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o 
> firmware/built-in.o net/built-in.o virt/built-in.o --end-group
> arch/powerpc/platforms/built-in.o: In function `bootx_printf':
> /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:88: 
> undefined reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function `bootx_add_display_props':
> /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:211: 
> undefined reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function 
> `bootx_scan_dt_build_struct':
> /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:350: 
> undefined reference to `__stack_chk_fail_local'
> arch/powerpc/platforms/built-in.o: In function `bootx_init':
> /usr/local/src/linux-git/arch/powerpc/platforms/powermac/bootx_init.c:596: 
> undefined reference to `__stack_chk_fail_local'
> /usr/bin/ld.bfd.real: .tmp_vmlinux1: hidden symbol `__stack_chk_fail_local' 
> isn't defined
> /usr/bin/ld.bfd.real: final link failed: Bad value
> 
> 
> 
> $ ld --version | head -1
> GNU ld (GNU Binutils for Debian) 2.25
> 
> $ gcc --version | head -1
> gcc-4.9.real (Debian 4.9.2-10) 4.9.2
> 
> 
> I'm regularly compiling userspace programs with -fstack-protector w/o 
> problems. I suspect it's either 6533b7c16ee5712041b4e324100550e02a9a5dda 
> ("powerpc: Initial stack protector (-fstack-protector) support") or 
> 902e06eb86cd62753974c249bd1dedae2825b430 ("powerpc/32: Change the stack 
> protector canary value per task") or both but I haven't started the 
> bisection yet.
> 
> Any other ideas?
> 
> Thanks,
> Christian.
> -- 
> BOFH excuse #220:
> 
> Someone thought The Big Red Button was a light switch.
> 

-- 
BOFH excuse #413:

Cow-tippers tipped a cow onto the server.