[Bug target/66491] New: x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library

[Bug target/66491] New: x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library

[dhowells at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491

            Bug ID: 66491
           Summary: x86_64 target cross-compiler generates stack protector
                    code unsuitable for the Linux kernel if the compiler
                    wasn't built against a C library
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dhowells at redhat dot com
  Target Milestone: ---

The Fedora gcc-5.1.1 cross-compiler targeting x86_64 doesn't generate
appropriate stack protection code as the compiler wasn't built against glibc.

For example, if the following command is run:

  echo "int foo(void) { char X[200]; return 3; }" |
  x86_64-linux-gnu-gcc -S -x c -c -O0 -mcmodel=kernel -fstack-protector - -o -

the code generated refers to __stack_chk_guard:
        ...
        movq    __stack_chk_guard(%rip), %rax
        movq    %rax, -8(%rbp)
        xorl    %eax, %eax
        movl    $3, %eax
        movq    -8(%rbp), %rdx
        xorq    __stack_chk_guard(%rip), %rdx
        je      .L3
        call    __stack_chk_fail
        ...

but it should instead use the %gs segment register to access the canary:
        ...
        movq    %gs:40, %rax
        movq    %rax, -8(%rbp)
        xorl    %eax, %eax
        movl    $3, %eax
        movq    -8(%rbp), %rdx
        xorq    %gs:40, %rdx
        je      .L3
        call    __stack_chk_fail
        ...

as is expected by the kernel.

This was originally logged in the Red Hat bugzilla as:

    https://bugzilla.redhat.com/show_bug.cgi?id=1228800

The reporter looked into how cross-gcc is built and the problem seems to be
this:
gcc is configured with "--without-headers". The configure script checks for
whether the target libc provides SSP (TARGET_LIBC_PROVIDES_SSP). In this case
it will be false.

The definition of TARGET_THREAD_SSP_OFFSET is conditional under "#ifdef
TARGET_LIBC_PROVIDES_SSP" (in gcc/config/i386/gnu-user64.h), so it will not be
defined.

config/i386/i386.md describes how to generate stack protector code. It will use
TLS canary only if "#ifdef TARGET_THREAD_SSP_OFFSET".

As per one of the reporter's suggestions, -mcmodel=kernel should perhaps switch
to the %gs method, overriding anything the gcc selects based on the C library.

[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library

[dhowells at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491

--- Comment #1 from dhowells at redhat dot com <dhowells at redhat dot com> ---
Configured with:

CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.1.1-20150422/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared
--disable-silent-rules --disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/x86_64-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin
--enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu
--includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec
--localstatedir=/var --mandir=/usr/share/man --prefix=/usr
--program-prefix=x86_64-linux-gnu- --sbindir=/usr/sbin
--sharedstatedir=/var/lib --sysconfdir=/etc --target=x86_64-linux-gnu
--with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-default-libstdcxx-abi=c++98 --with-isl --with-linker-hash-style=gnu
--with-newlib --with-sysroot=/usr/x86_64-linux-gnu/sys-root
--with-system-libunwind --with-system-zlib --without-headers

Built with:

AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \
make -C x86_64-linux-gnu -j5 tooldir=/usr all-gcc
make -C x86_64-linux-gnu
DESTDIR=/home/dhowells/rpmbuild/BUILDROOT/cross-gcc-5.1.1-2.fc22.x86_64
install-gcc install-target-libgcc

The binutils was 2.25 cross-compiled for x86_64.

[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library

[dhowells at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491

--- Comment #2 from dhowells at redhat dot com <dhowells at redhat dot com> ---
Possibly -mcmodel=kernel shouldn't be overloaded, but -fstack-protector should
be - perhaps to have a -fstack-protector-gs option or similar.