Build fails with -fstack-protector-* in target CFLAGS

Question

Build fails with -fstack-protector-* in target CFLAGS

phpstatic opened this issue 4 years ago · comments

today I start useGCC_CONFIG += --enable-libssp.

x86_64-linux-musl-gcc -static-libgcc -static-pie   xtest.c -lz -lm

gdb:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) r
Starting program:  ./a.out 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7df57dc in inflateStateCheck ()
(gdb) bt
#0  0x00007ffff7df57dc in inflateStateCheck ()
#1  0x00007ffff7df6e7a in inflateEnd ()
#2  0x00007ffff7df5693 in main () at xtest.c:78

my config.mk

XSTAT = -static --static
XARCH = -march=x86-64 -mtune=generic
XFLAG = -g -Og -mlong-double-64 -fno-plt -DNDEBUG -fomit-frame-pointer -m64
XCPU  = -mmmx -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -maes -mavx
XSSP  = -fstack-protector-strong
XMUSL = "${XFLAG} ${XCPU} ${XSSP}"

COMMON_CONFIG += CFLAGS="${XARCH} ${XFLAG} ${XCPU}"
COMMON_CONFIG += CXXFLAGS="${XARCH} ${XFLAG} ${XCPU}"
COMMON_CONFIG += LDFLAGS="${XSTAT}"

COMMON_CONFIG += --disable-nls --disable-lto
GCC_CONFIG += --disable-libquadmath --disable-decimal-float --disable-libitm --disable-fixed-point
GCC_CONFIG += --disable-multilib
GCC_CONFIG += --disable-shared
GCC_CONFIG += --enable-static
GCC_CONFIG += --enable-ld
GCC_CONFIG += --enable-default-pie --enable-static-pie
GCC_CONFIG += --enable-libssp --enable-default-ssp
GCC_CONFIG += --with-long-double-64
GCC_CONFIG += --with-isl
#GCC_CONFIG_FOR_TARGET  += 

MUSL_CONFIG += CFLAGS="${XARCH} ${XMUSL}" CXXFLAGS="${XARCH} ${XMUSL}" LDFLAGS="-s ${XSTAT}"
MUSL_CONFIG += --enable-optimize=yes --disable-shared

I also try remove --enable-default-ssp, add -g0 -O3`, get same error

phpstatic.com · Answer 1 · Fri Feb 14 2020 21:55:35 GMT+0800 (China Standard Time)

some how I try rebuild fresh again, not get stop error.

Rich Felker · Answer 2 · Fri Feb 14 2020 22:11:20 GMT+0800 (China Standard Time)

What's happening contrary to your expectation? Apparently the program you're compiling has one or more bugs leading to invalid memory access.

phpstatic.com · Answer 3 · Fri Feb 14 2020 22:56:44 GMT+0800 (China Standard Time)

First time I try with ssp configure throw error and stop, I try cope the code from config.log and test it, then get that Segmentation.

After I clear every thing and rebuild, the configure pass but the example I create from fist config.log still Segmentation. I guess it should Segmentation for this case but some other problem stop my first configure run success.

Rich Felker · Answer 4 · Fri Feb 14 2020 23:55:42 GMT+0800 (China Standard Time)

As an aside, some options in your build are definitely broken/invalid, like --with-long-double-64. Unless GCC just ignores it this should cause the build to error out while building musl (you can't just change ABI like that). --disable-shared is possibly also broken; I'm not sure.

Also the flags you're passing via XFLAG etc. make no sense; in one place (COMMON_CONFIG) they're affecting the flags that the cross compiler (to run on your host) is build with; in other places (MUSL_CONFIG) they're affecting the flags for code built to run on the target. And again many of these options are breaking/invalid.

Rich Felker · Answer 5 · Sat Feb 15 2020 00:02:12 GMT+0800 (China Standard Time)

It looks like this particular case is not presently caught in musl's build process, which is an oversight; I'll fix it. But you really need to remove those options. They will badly break lots of code including code that does not use long double at all (at least printf and scanf/strtod family, maybe others).

Rich Felker · Answer 6 · Sat Feb 15 2020 00:03:40 GMT+0800 (China Standard Time)

Back to your crash, are you saying that the crashing program is a test that one of the configure scripts is running during build? Can you show which one it is? It looks to me like it's a program you're trying to compile yourself so I'm confused.

phpstatic.com · Answer 7 · Sat Feb 15 2020 00:26:50 GMT+0800 (China Standard Time)

are you saying that the crashing program is a test that one of the configure scripts is running during build? Can you show which one it is?

It is the configure scripts for zlib from tiff-3.9.7, and i try rebuild every things few time, all is ok.

Also the flags you're passing via XFLAG etc. make no sense; in one place (COMMON_CONFIG) they're affecting the flags that the cross compiler (to run on your host) is build with; in other places (MUSL_CONFIG) they're affecting the flags for code built to run on the target. And again many of these options are breaking/invalid.

Thanks for the explain.

--disable-shared is work for me, since I use the toolchain only build static binary, zero use case for dynamic library.

I just want to make sure the target lib libc.a, libpthread.a, libstdc++.a, libgcc.a to build the options I provide, don care the x86_64-linux-musl-gcc. is this config.mk work for this ?

XLD = -s
XARCH = -march=x86-64 -mtune=generic
XFLAG = -g0 -O3 -mlong-double-64 -fno-plt -DNDEBUG -fomit-frame-pointer -m64
XCPU  = -mmmx -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -maes -mavx
XSSP  = -fstack-protector-strong
XMUSL = "${XARCH} ${XFLAG} ${XCPU} ${XSSP}"

COMMON_CONFIG += --disable-nls --disable-lto
GCC_CONFIG += --disable-libquadmath --disable-decimal-float --disable-libitm --disable-fixed-point
GCC_CONFIG += --disable-multilib
GCC_CONFIG += --disable-shared
GCC_CONFIG += --enable-static
GCC_CONFIG += --enable-ld
GCC_CONFIG += --enable-default-pie --enable-static-pie
GCC_CONFIG += --enable-libssp --enable-default-ssp
GCC_CONFIG += --with-isl

GCC_CONFIG_FOR_TARGET   += CFLAGS="${XMUSL}" CXXFLAGS="${XARCH} ${XMUSL}" LDFLAGS="${XLD}"
MUSL_CONFIG += CFLAGS="${XMUSL}" CXXFLAGS="${XARCH} ${XMUSL}" LDFLAGS="${XLD}"
MUSL_CONFIG += --enable-optimize=yes --disable-shared

phpstatic.com · Answer 8 · Sat Feb 15 2020 00:30:44 GMT+0800 (China Standard Time)

and one more question , the musl-cross-make generate static pie binary for me

checksec -f sapi/cli/php
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	Symbols		FORTIFY	Fortified	Fortifiable  FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   79864 Symbols

but after I strip it,

checksec -f sapi/cli/php
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	Symbols		FORTIFY	Fortified	Fortifiable  FILE
Full RELRO      No canary found   NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols       No	0		0	sapi/cli/php

I think FORTIFY and STACK CANARY is part of binary, not symbols, why strip remove them ?

Rich Felker · Answer 9 · Sat Feb 15 2020 00:31:53 GMT+0800 (China Standard Time)

-mlong-double-64 is definitely broken and will produce a broken libc. It was supposed to be caught by musl build process and rejected but apparently that's not working. You really need to remove it.

In addition this:

GCC_CONFIG_FOR_TARGET   += CFLAGS="${XMUSL}" CXXFLAGS="${XARCH} ${XMUSL}" LDFLAGS="${XLD}"

should be:

GCC_CONFIG   += CFLAGS_FOR_TARGET="${XMUSL}" CXXFLAGS_FOR_TARGET="${XARCH} ${XMUSL}" LDFLAGS_FOR_TARGET="${XLD}"

Rich Felker · Answer 10 · Sat Feb 15 2020 00:34:44 GMT+0800 (China Standard Time)

Re: checksec output, I don't know what that script/utility does, but there is no way strip can remove stack protector or otherwise alter the security properties of a program. It probably just fails to see it's in use because of lack of symbols.

phpstatic.com · Answer 11 · Sat Feb 15 2020 00:41:01 GMT+0800 (China Standard Time)

I adjust it to this and rebuild, hope every things work.

COMMON_CONFIG += --disable-nls --disable-lto
GCC_CONFIG += --disable-libquadmath --disable-decimal-float --disable-libitm --disable-fixed-point
GCC_CONFIG += --disable-multilib
GCC_CONFIG += --disable-shared
GCC_CONFIG += --enable-static
GCC_CONFIG += --enable-ld
GCC_CONFIG += --enable-default-pie --enable-static-pie
GCC_CONFIG += --enable-libssp --enable-default-ssp
GCC_CONFIG += --with-isl

XLD = -s
XCC = -march=x86-64 -mtune=generic -g0 -O3 -fno-plt -DNDEBUG -fomit-frame-pointer -m64 -mmmx -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -maes -mavx -fstack-protector-strong

GCC_CONFIG_FOR_TARGET   += CFLAGS_FOR_TARGET="${XCC}" CXXFLAGS_FOR_TARGET="${XCC}" LDFLAGS_FOR_TARGET="${XLD}"
MUSL_CONFIG += CFLAGS="${XCC}" CXXFLAGS="${XCC}" LDFLAGS="${XLD}"
MUSL_CONFIG += --enable-optimize=yes --disable-shared

phpstatic.com · Answer 12 · Sat Feb 15 2020 00:51:43 GMT+0800 (China Standard Time)

The build stop at step obj_gcc/x86_64-linux-musl/libgomp, because x86_64-linux-musl/obj_binutils/ld/ld-new: cannot find -lssp_nonshared

I need remove -fstack-protector-strong from GCC_CONFIG_FOR_TARGET and MUSL_CONFIG

Rich Felker · Answer 13 · Sat Feb 15 2020 01:38:14 GMT+0800 (China Standard Time)

I'm not sure GCC supports building its own target libs with -fstack-protector-strong; it might explicitly disable stack protector for some files, only to have it overridden by that. But the problem linking libssp_nonshared.a may be a genuine problem. Can you reproduce the problem with a minimal set of weird/nondefault config?

phpstatic.com · Answer 14 · Sat Feb 15 2020 01:54:15 GMT+0800 (China Standard Time)

Can you reproduce the problem with a minimal set of weird/nondefault config?

I will do it tomorrow, I guess add -fstack-protector to GCC_CONFIG_FOR_TARGET or MUSL_CONFIG will create the problem.

with my last post config.mk, I remove -fstack-protector-strong make it work for me.

Rich Felker · Answer 15 · Sat Feb 15 2020 01:58:54 GMT+0800 (China Standard Time)

I'm trying a run with just -fstack-protector-strong added to CFLAGS_FOR_TARGET to see if I can reproduce the problem.

Rich Felker · Answer 16 · Sat Feb 15 2020 02:27:40 GMT+0800 (China Standard Time)

Indeed, I can reproduce this. I think building gcc target libs with -fstack-protector-* is presently unsupported. I'm not sure about --enable-default-ssp; GCC might just disable ssp for its own target libs in that case.

For musl, you can use -fstack-protector-strong, as it does not use GCC's libssp_nonshared.a but provides its own local version of the symbol if needed (and it's not needed on x86_64 anyway).

I will try to improve this in a future version but for now I think you should just remove the option (from gcc target libs; you can keep it for musl).

phpstatic.com · Answer 17 · Sat Feb 15 2020 15:34:55 GMT+0800 (China Standard Time)

I confirm CFLAGS_FOR_TARGET not work with stack-protector, MUSL work with it.