On Fri, Jul 17, 2020 at 6:27 AM Richard Biener <rguent...@suse.de> wrote:
>
> On Fri, 17 Jul 2020, H.J. Lu wrote:
>
> > On Fri, Jul 17, 2020 at 12:08 AM Richard Biener <rguent...@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.
> 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.
