[PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

Subsystems: linux for powerpc (32-bit and 64-bit), the rest

STALE2885d

6 messages, 4 authors, 2018-10-15 · open the first message on its own page

[PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2018-10-12 23:00:20

If GCC is not built with glibc support then we must explicitly tell it
which register to use for TLS mode stack protector, otherwise it will
error out and the cc-option check will fail.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1888636c9eb6..3d008115fe18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -180,7 +180,8 @@ config PPC
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_CBPF_JIT			if !PPC64
-	select HAVE_STACKPROTECTOR		if $(cc-option,-mstack-protector-guard=tls)
+	select HAVE_STACKPROTECTOR		if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
+	select HAVE_STACKPROTECTOR		if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
 	select HAVE_CONTEXT_TRACKING		if PPC64
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_DEBUG_STACKOVERFLOW
-- 
2.17.1

Re: [PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

From: Christophe LEROY <hidden>
Date: 2018-10-13 07:34:10


Le 13/10/2018 à 00:58, Michael Ellerman a écrit :
If GCC is not built with glibc support then we must explicitly tell it
which register to use for TLS mode stack protector, otherwise it will
error out and the cc-option check will fail.
Oh ? I didn't encounter such a problem with the nolibc GCC from 
https://mirrors.edge.kernel.org/pub/tools/crosstool/

I did all my tests with powerpc64-linux-gcc 8.1 on x86_64

Christophe
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Christophe Leroy <redacted>
quoted hunk
---
  arch/powerpc/Kconfig | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1888636c9eb6..3d008115fe18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -180,7 +180,8 @@ config PPC
  	select HAVE_ARCH_SECCOMP_FILTER
  	select HAVE_ARCH_TRACEHOOK
  	select HAVE_CBPF_JIT			if !PPC64
-	select HAVE_STACKPROTECTOR		if $(cc-option,-mstack-protector-guard=tls)
+	select HAVE_STACKPROTECTOR		if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
+	select HAVE_STACKPROTECTOR		if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
  	select HAVE_CONTEXT_TRACKING		if PPC64
  	select HAVE_DEBUG_KMEMLEAK
  	select HAVE_DEBUG_STACKOVERFLOW

Re: [PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2018-10-13 11:57:05

Christophe LEROY [off-list ref] writes:
Le 13/10/2018 à 00:58, Michael Ellerman a écrit :
quoted
If GCC is not built with glibc support then we must explicitly tell it
which register to use for TLS mode stack protector, otherwise it will
error out and the cc-option check will fail.
Oh ? I didn't encounter such a problem with the nolibc GCC from 
https://mirrors.edge.kernel.org/pub/tools/crosstool/
Yes, you're right.

  $ /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -o empty.o -Wall -c empty.c -mstack-protector-guard=tls 
  $ echo $?
  0

But with mine:
  $ /home/kerkins/toolchains/ppc/gcc-8-branch/powerpc-linux/bin/powerpc-linux-gcc -o empty.o -Wall -c empty.c -mstack-protector-guard=tls 
  cc1: error: ‘-mstack-protector-guard=tls’ needs a valid base register


So it's only my cross compilers that don't work.

The kernel.org ones are:
  Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
  --enable-targets=all
  --prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux
  --enable-languages=c --without-headers --disable-bootstrap
  --disable-nls --disable-threads --disable-shared --disable-libmudflap
  --disable-libssp --disable-libgomp --disable-decimal-float
  --disable-libquadmath --disable-libatomic --disable-libcc1
  --disable-libmpx --enable-checking=release

Whereas mine is:
  Configured with: ../../src/gcc/configure
  --prefix=/home/kerkins/workspace/gcc-build/gcc/gcc-8-branch/target/ppc/build/install/powerpc-linux
  --disable-multilib --disable-bootstrap --enable-languages=c
  --with-pkgversion='Custom 2c79ff811dfcee1c' --target=powerpc-linux
  --enable-targets=all


So I wonder if something in there is making the difference?

I guess I'll just rewrite the change log to say "some toolchains".

cheers

Re: [PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

From: Segher Boessenkool <hidden>
Date: 2018-10-13 15:50:40

On Sat, Oct 13, 2018 at 10:55:01PM +1100, Michael Ellerman wrote:
So it's only my cross compilers that don't work.

The kernel.org ones are:
  Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
  --enable-targets=all
  --prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux
  --enable-languages=c --without-headers --disable-bootstrap
  --disable-nls --disable-threads --disable-shared --disable-libmudflap
  --disable-libssp --disable-libgomp --disable-decimal-float
  --disable-libquadmath --disable-libatomic --disable-libcc1
  --disable-libmpx --enable-checking=release

Whereas mine is:
  Configured with: ../../src/gcc/configure
  --prefix=/home/kerkins/workspace/gcc-build/gcc/gcc-8-branch/target/ppc/build/install/powerpc-linux
  --disable-multilib --disable-bootstrap --enable-languages=c
  --with-pkgversion='Custom 2c79ff811dfcee1c' --target=powerpc-linux
  --enable-targets=all


So I wonder if something in there is making the difference?
You have --disable-libssp on the buildall-built compiler, which makes GCC
assume your libc has the SSP support routines, which gives you these default
offsets (which are what they are on glibc).  Never mind that you explicitly
do not have a libc ;-)
I guess I'll just rewrite the change log to say "some toolchains".
Or "most".


Segher

Re: powerpc: Fix stackprotector detection for non-glibc toolchains

From: Michael Ellerman <hidden>
Date: 2018-10-15 04:42:35

On Fri, 2018-10-12 at 22:58:32 UTC, Michael Ellerman wrote:
If GCC is not built with glibc support then we must explicitly tell it
which register to use for TLS mode stack protector, otherwise it will
error out and the cc-option check will fail.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Christophe Leroy <redacted>
Applied to powerpc next.

https://git.kernel.org/powerpc/c/bf6cbd0c87f30d0e4401be91a8161c

cheers

Re: [PATCH] powerpc: Fix stackprotector detection for non-glibc toolchains

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2018-10-15 09:54:17

Segher Boessenkool [off-list ref] writes:
On Sat, Oct 13, 2018 at 10:55:01PM +1100, Michael Ellerman wrote:
quoted
So it's only my cross compilers that don't work.

The kernel.org ones are:
  Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
  --enable-targets=all
  --prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux
  --enable-languages=c --without-headers --disable-bootstrap
  --disable-nls --disable-threads --disable-shared --disable-libmudflap
  --disable-libssp --disable-libgomp --disable-decimal-float
  --disable-libquadmath --disable-libatomic --disable-libcc1
  --disable-libmpx --enable-checking=release

Whereas mine is:
  Configured with: ../../src/gcc/configure
  --prefix=/home/kerkins/workspace/gcc-build/gcc/gcc-8-branch/target/ppc/build/install/powerpc-linux
  --disable-multilib --disable-bootstrap --enable-languages=c
  --with-pkgversion='Custom 2c79ff811dfcee1c' --target=powerpc-linux
  --enable-targets=all


So I wonder if something in there is making the difference?
You have --disable-libssp on the buildall-built compiler, which makes GCC
assume your libc has the SSP support routines, which gives you these default
offsets (which are what they are on glibc).  Never mind that you explicitly
do not have a libc ;-)
OK thanks, things just get weirder and weirder :)
quoted
I guess I'll just rewrite the change log to say "some toolchains".
Or "most".
As it happens I forgot to update the change log anyway :/

Oh well.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help