[PATCH] Require CET support only for the final GCC build

[Richard Biener]

On Wed, 29 Jul 2020, Richard Biener wrote:

> On Fri, Jul 17, 2020 at 5:32 PM H.J. Lu via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > On Fri, Jul 17, 2020 at 6:27 AM Richard Biener <rguenther@suse.de> wrote:
> > >
> > > On Fri, 17 Jul 2020, H.J. Lu wrote:
> > >
> > > > On Fri, Jul 17, 2020 at 12:08 AM Richard Biener <rguenther@suse.de> wrote:
> > > > >
> > > > > On Wed, 15 Jul 2020, Joseph Myers wrote:
> > > > >
> > > > > > On Wed, 15 Jul 2020, Richard Biener wrote:
> > > > > >
> > > > > > > But note one of the issues is that when not cross-compiling we're
> > > > > > > using a single libiberty for target and host objects (likewise
> > > > > >
> > > > > > There shouldn't be a target libiberty, since commit
> > > > > > 8499116aa30a46993deff5acf73985df6b16fb8b (re PR regression/47836 (Some
> > > > > > Cross Compiler can't build target-libiberty or target-zlib), Wed Jun 22
> > > > > > 19:40:45 2011 +0000).  If something is causing target libiberty to be
> > > > > > built, that's a bug that should be fixed.
> > > > > >
> > > > > > > That said, giving configury an idea whether it configures for
> > > > > > > the host, the target or the build would be required here - Joseph,
> > > > > > > is there an existing mechanism for example libiberty can use
> > > > > > > here?
> > > > > >
> > > > > > Makefile.def has some settings specific to host or build, e.g.
> > > > > >
> > > > > > build_modules= { module= libcpp;
> > > > > >                  extra_configure_flags='--disable-nls am_cv_func_iconv=no';};
> > > > > >
> > > > > > or
> > > > > >
> > > > > > host_modules= { module= libiberty; bootstrap=true;
> > > > > >                 extra_configure_flags='@extra_host_libiberty_configure_flags@';};
> > > > >
> > > > > Ah, OK.  Looks like we should be able to add a
> > > > > @extra_target_cet_configure_flags@, funnel that to the target_modules
> > > > > and keep CET disabled by default in the modules configury.
> > > > >
> > > > > Similarly (if HJ is correct) we'd need to add
> > > > > @extra_{host,build}_cet_configure_flags@ for the purpose of lto-plugin
> > > > > which only has a host module (and for bootstrap host == build, so it's
> > > > > shared there but we still have separate libiberties for host/build...)
> > > > >
> > > >
> > > > We need -fcf-protection only on object files which will be dlopened on
> > > > CET enabled build and host.
> > >
> > > Why is there a distinction between dlopen and execution?  IIRC
> > > ld falls back to non-CET operation when dlopening a non-CET shared object?
> >
> > BTW, ld.so refuses to dlopen a legacy shared object after CET has been enabled.
> > This behavior can be controlled when configuring glibc:
> >
> > '--enable-cet'
> > '--enable-cet=permissive'
> >      Enable Intel Control-flow Enforcement Technology (CET) support.
> >      When the GNU C Library is built with '--enable-cet' or
> >      '--enable-cet=permissive', the resulting library is protected with
> >      indirect branch tracking (IBT) and shadow stack (SHSTK).  When CET
> >      is enabled, the GNU C Library is compatible with all existing
> >      executables and shared libraries.  This feature is currently
> >      supported on i386, x86_64 and x32 with GCC 8 and binutils 2.29 or
> >      later.  Note that when CET is enabled, the GNU C Library requires
> >      CPUs capable of multi-byte NOPs, like x86-64 processors as well as
> >      Intel Pentium Pro or newer.  With '--enable-cet', it is an error to
> >      dlopen a non CET enabled shared library in CET enabled application.
> >      With '--enable-cet=permissive', CET is disabled when dlopening a
> >      non CET enabled shared library in CET enabled application.
> 
> So getting back to this one of the issues is that --enable-cet is used
> for both GCC_CET_FLAGS and GCC_CET_HOST_FLAGS where
> for the host flag part I'd use --enable-cet=auto but for the target library
> part I definitely want to know if --enable-cet cannot be honored.
> 
> Your current patch would still prohibit a non-bootstrap build with a host
> compiler not supporting CET and requesting CET enabled target libraries,
> thus
> 
> ../configure --enable-cet --disable-bootstrap
> 
> would fail.  Shouldn't we - for the host part - simply treat 'yes' equal
> to 'auto'?  If not, then we should have --enable-cet-host.  Which would
> be somewhat misleading since cc1 isn't built CET enabled, just
> lto-plugin.so is, so better --enable-lto-plugin-cet?
> 
> Thus I'd go with the simpler of both:
> 
> diff --git a/config/cet.m4 b/config/cet.m4
> index d9608699cd5..fb4e4275413 100644
> --- a/config/cet.m4
> +++ b/config/cet.m4
> @@ -64,7 +64,7 @@ case "$host" in
>      save_CFLAGS="$CFLAGS"
>      CFLAGS="$CFLAGS -fcf-protection"
>      case "$enable_cet" in
> -      auto)
> +      auto|yes)
>         # Check if target supports multi-byte NOPs
>         # and if assembler supports CET insn.
>         AC_COMPILE_IFELSE(
> @@ -80,15 +80,6 @@ asm ("setssbsy");
>          [enable_cet=yes],
>          [enable_cet=no])
>         ;;
> -      yes)
> -       # Check if assembler supports CET.
> -       AC_COMPILE_IFELSE(
> -        [AC_LANG_PROGRAM(
> -         [],
> -         [asm ("setssbsy");])],
> -        [],
> -        [AC_MSG_ERROR([assembler with CET support is required for
> --enable-cet])])
> -       ;;
>      esac
>      CFLAGS="$save_CFLAGS"
>      ;;
> 
> is that OK with you?

Verified it fixes bootstrap & non-bootstrap with --enable-cet
and a GCC 7 host compiler.  I also verified the target libs
are built CET enabled (starting with stage1) and that lto-plugin
is as well (post stage1 but not when not bootstrapping).

Richard.

> Thanks,
> Richard.
> 
> > > But OK, so if we'll allow mixing CET and non-CET objects for the
> > > gen* link, simply dropping CET enablement, I guess it will work
> > > as it did before.
> > >
> > > Richard.
> >
> >
> >
> > --
> > H.J.
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)