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

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

[Christian Kujau]

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

Someone thought The Big Red Button was a light switch.

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.

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 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'

[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'

[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'

[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'

[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'

[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, 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'

[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'

[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'

[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'

[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'

[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'

[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'

[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)

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

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'

[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'

[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'

[David Laight]

From: Christophe LEROY
> Sent: 13 January 2017 12:15
...
> > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would norma=
lly
> > be true for glibc >=3D 2.4), and that is all.  Mystery solved.  Thanks!
> >
>=20
> Is there a way to know during compilation how the compiler will behave,
> in order to select the correct method ?
>=20
> 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