HEADSUP: toolchain modifications required for built-in SSP

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

HEADSUP: toolchain modifications required for built-in SSP

Yaakov Selkowitz-2
Newlib/RTEMS users,

Please be aware that, as of today's git master, and the next (2.6.0?)
tarball release, Newlib includes its own implementation of Stack
Smashing Protection (-fstack-protector*) and Object Size Checking
(-D_FORTIFY_SOURCE=*) features.  This implementation replaces and
conflicts with GCC's libssp, which is practically broken and unmaintained.

In order to avoid the conflict with GCC's libssp, Newlib/RTEMS
toolchains using git master or the next release MUST be rebuilt,
configuring with the --disable-libssp flag, and exporting
gcc_cv_libc_provides_ssp=yes in the environment during 'make'.

If you have any issues with these features, please feel free to ask on list.

--
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Sebastian Huber-4
On 30/11/17 02:43, Yaakov Selkowitz wrote:

> Newlib/RTEMS users,
>
> Please be aware that, as of today's git master, and the next (2.6.0?)
> tarball release, Newlib includes its own implementation of Stack
> Smashing Protection (-fstack-protector*) and Object Size Checking
> (-D_FORTIFY_SOURCE=*) features.  This implementation replaces and
> conflicts with GCC's libssp, which is practically broken and unmaintained.
>
> In order to avoid the conflict with GCC's libssp, Newlib/RTEMS
> toolchains using git master or the next release MUST be rebuilt,
> configuring with the --disable-libssp flag,

Since libssp was apparently broken, the --disable-libssp does no harm if
used with older Newlib versions?

> and exporting
> gcc_cv_libc_provides_ssp=yes in the environment during 'make'.

I think this should be fixed for Newlib in general in the GCC
gcc/configure.ac:

# Test for stack protector support in target C library.
AC_CACHE_CHECK(__stack_chk_fail in target C library,
       gcc_cv_libc_provides_ssp,
       [gcc_cv_libc_provides_ssp=no
     case "$target" in
        *-*-musl*)
      # All versions of musl provide stack protector
      gcc_cv_libc_provides_ssp=yes;;
        *-*-linux* | *-*-kfreebsd*-gnu)
       # glibc 2.4 and later provides __stack_chk_fail and
       # either __stack_chk_guard, or TLS access to stack guard canary.
       GCC_GLIBC_VERSION_GTE_IFELSE([2], [4],
[gcc_cv_libc_provides_ssp=yes], [
       [if test -f $target_header_dir/features.h \
      && $EGREP '^[     ]*#[     ]*define[ ]+__GNU_LIBRARY__[    
]+([1-9][0-9]|[6-9])' \
         $target_header_dir/features.h > /dev/null; then
     if $EGREP '^[     ]*#[     ]*define[     ]+__UCLIBC__[     ]+1' \
          $target_header_dir/features.h > /dev/null && \
          test -f $target_header_dir/bits/uClibc_config.h && \
          $EGREP '^[     ]*#[     ]*define[     ]+__UCLIBC_HAS_SSP__[
     ]+1' \
          $target_header_dir/bits/uClibc_config.h > /dev/null; then
       gcc_cv_libc_provides_ssp=yes
     fi
       # all versions of Bionic support stack protector
       elif test -f $target_header_dir/sys/cdefs.h \
         && $EGREP '^[  ]*#[    ]*define[ ]+__BIONIC__[   ]+1' \
            $target_header_dir/sys/cdefs.h > /dev/null; then
          gcc_cv_libc_provides_ssp=yes
       fi]])
     ;;
        *-*-gnu*)
      # Avoid complicated tests (see
      # <http://gcc.gnu.org/ml/gcc/2008-10/msg00130.html>) and for now
      # simply assert that glibc does provide this, which is true for all
      # realistically usable GNU/Hurd configurations.
      # All supported versions of musl provide it as well
      gcc_cv_libc_provides_ssp=yes;;
        *-*-darwin* | *-*-freebsd* | *-*-netbsd*)
      AC_CHECK_FUNC(__stack_chk_fail,[gcc_cv_libc_provides_ssp=yes],
            [echo "no __stack_chk_fail on this target"])
         ;;
   *) gcc_cv_libc_provides_ssp=no ;;
     esac])

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Yaakov Selkowitz
On 2017-11-30 02:07, Sebastian Huber wrote:

> On 30/11/17 02:43, Yaakov Selkowitz wrote:
>> Newlib/RTEMS users,
>>
>> Please be aware that, as of today's git master, and the next (2.6.0?)
>> tarball release, Newlib includes its own implementation of Stack
>> Smashing Protection (-fstack-protector*) and Object Size Checking
>> (-D_FORTIFY_SOURCE=*) features.  This implementation replaces and
>> conflicts with GCC's libssp, which is practically broken and
>> unmaintained.
>>
>> In order to avoid the conflict with GCC's libssp, Newlib/RTEMS
>> toolchains using git master or the next release MUST be rebuilt,
>> configuring with the --disable-libssp flag,
>
> Since libssp was apparently broken, the --disable-libssp does no harm if
> used with older Newlib versions?
libssp's -fstack-protector* works fine (as long as you link with that
flag too), but -D_FORTIFY_SOURCE=* is completely broken.  Disabling it
now would prevent both.

>> and exporting
>> gcc_cv_libc_provides_ssp=yes in the environment during 'make'.
>
> I think this should be fixed for Newlib in general in the GCC
> gcc/configure.ac:

I have attached patches for 5/6/7 and 8 (trunk) which I could propose,
but I don't know if it will get into stable versions in time, and in
trunk, it appears --disable-libssp will be enough by itself.  In the
meantime, export gcc_cv_libc_provides_ssp=yes is a workaround.

--
Yaakov

gcc7-ssp-newlib.patch (1K) Download Attachment
gcc8-ssp-newlib.patch (1K) Download Attachment
signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Sebastian Huber-4
It would be nice to have a snapshot before the next release to test
this. Is the next release 3.0.0 (due to the 64-bit time_t) or 2.6.0?

On 30/11/17 11:41, Yaakov Selkowitz wrote:

> gcc8-ssp-newlib.patch
>
>
> 2017-11-29  Yaakov Selkowitz<[hidden email]>
>
> gcc/
> * configure.ac (gcc_cv_libc_provides_ssp): Define as yes
> on Newlib-based targets if new builtin SSP support is present.
> * configure: Regenerate.
>
> Index: gcc/configure
> ===================================================================
> --- gcc/configure (revision 255250)
> +++ gcc/configure (working copy)
> @@ -29100,6 +29100,12 @@
>   fi
>  
>           ;;
> +       *-*-cygwin* | *-*-rtems* | *-*-eabi* | *-*-elf* | mmix-knuth-mmixware)

Instead of this target enumeration, could we not use an $EGREP approach
similar to some other libc variants?

> +         # This is a recent addition to Newlib/Cygwin/RTEMS

The "recent addition" is probably no longer that recent in one or two
years. Maybe we should use a version or date here, e.g. since Newlib
snapshot XYZ.

> +         if test -f $target_header_dir/ssp/ssp.h; then
> +           gcc_cv_libc_provides_ssp=yes
> +         fi
> +        ;;
>          *) gcc_cv_libc_provides_ssp=no ;;
>       esac
>     fi

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Corinna Vinschen
On Dec  4 08:32, Sebastian Huber wrote:

> It would be nice to have a snapshot before the next release to test this. Is
> the next release 3.0.0 (due to the 64-bit time_t) or 2.6.0?
>
> On 30/11/17 11:41, Yaakov Selkowitz wrote:
> > gcc8-ssp-newlib.patch
> >
> >
> > 2017-11-29  Yaakov Selkowitz<[hidden email]>
> >
> > gcc/
> > * configure.ac (gcc_cv_libc_provides_ssp): Define as yes
> > on Newlib-based targets if new builtin SSP support is present.
> > * configure: Regenerate.
> >
> > Index: gcc/configure
> > ===================================================================
> > --- gcc/configure (revision 255250)
> > +++ gcc/configure (working copy)
> > @@ -29100,6 +29100,12 @@
> >   fi
> >           ;;
> > +       *-*-cygwin* | *-*-rtems* | *-*-eabi* | *-*-elf* | mmix-knuth-mmixware)
>
> Instead of this target enumeration, could we not use an $EGREP approach
> similar to some other libc variants?
Can you make up an example?

> > +         # This is a recent addition to Newlib/Cygwin/RTEMS
>
> The "recent addition" is probably no longer that recent in one or two years.
> Maybe we should use a version or date here, e.g. since Newlib snapshot XYZ.

Good point.  Date should suffice, I think,

>
> > +         if test -f $target_header_dir/ssp/ssp.h; then
> > +           gcc_cv_libc_provides_ssp=yes
> > +         fi
> > +        ;;
> >          *) gcc_cv_libc_provides_ssp=no ;;
> >       esac
> >     fi

Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Sebastian Huber-4
On 04/12/17 10:05, Corinna Vinschen wrote:

> On Dec  4 08:32, Sebastian Huber wrote:
>> It would be nice to have a snapshot before the next release to test this. Is
>> the next release 3.0.0 (due to the 64-bit time_t) or 2.6.0?
>>
>> On 30/11/17 11:41, Yaakov Selkowitz wrote:
>>> gcc8-ssp-newlib.patch
>>>
>>>
>>> 2017-11-29  Yaakov Selkowitz<[hidden email]>
>>>
>>> gcc/
>>> * configure.ac (gcc_cv_libc_provides_ssp): Define as yes
>>> on Newlib-based targets if new builtin SSP support is present.
>>> * configure: Regenerate.
>>>
>>> Index: gcc/configure
>>> ===================================================================
>>> --- gcc/configure (revision 255250)
>>> +++ gcc/configure (working copy)
>>> @@ -29100,6 +29100,12 @@
>>>    fi
>>>            ;;
>>> +       *-*-cygwin* | *-*-rtems* | *-*-eabi* | *-*-elf* | mmix-knuth-mmixware)
>> Instead of this target enumeration, could we not use an $EGREP approach
>> similar to some other libc variants?
> Can you make up an example?

The other libc use something like this:

        *-*-linux* | *-*-kfreebsd*-gnu)
       # glibc 2.4 and later provides __stack_chk_fail and
       # either __stack_chk_guard, or TLS access to stack guard canary.
       GCC_GLIBC_VERSION_GTE_IFELSE([2], [4],
[gcc_cv_libc_provides_ssp=yes], [
       [if test -f $target_header_dir/features.h \
      && $EGREP '^[     ]*#[     ]*define[ ]+__GNU_LIBRARY__[    
]+([1-9][0-9]|[6-9])' \
         $target_header_dir/features.h > /dev/null; then
     if $EGREP '^[     ]*#[     ]*define[     ]+__UCLIBC__[     ]+1' \
          $target_header_dir/features.h > /dev/null && \
          test -f $target_header_dir/bits/uClibc_config.h && \
          $EGREP '^[     ]*#[     ]*define[     ]+__UCLIBC_HAS_SSP__[
     ]+1' \
          $target_header_dir/bits/uClibc_config.h > /dev/null; then
       gcc_cv_libc_provides_ssp=yes
     fi
       # all versions of Bionic support stack protector
       elif test -f $target_header_dir/sys/cdefs.h \
         && $EGREP '^[  ]*#[    ]*define[ ]+__BIONIC__[   ]+1' \
            $target_header_dir/sys/cdefs.h > /dev/null; then
          gcc_cv_libc_provides_ssp=yes
       fi]])

The patch uses "*-*-cygwin* | *-*-rtems* | *-*-eabi* | *-*-elf* |
mmix-knuth-mmixware)" to determine if the libc is Newlib. It will
probably not work with a "*-*-phoenix*" target with uses Newlib.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Reply | Threaded
Open this post in threaded view
|

Re: HEADSUP: toolchain modifications required for built-in SSP

Sebastian Huber-4
In reply to this post by Yaakov Selkowitz-2
Hello Yaakov,

do you have a small test program to check if everything is all right?
Ideally under a BSD licence. I would like to add something to the RTEMS
test suite to ensure that the tool chain is good.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.