[Bug target/83087] -fcf-protection -mcet enabled unconditionally for target libs

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 19 Dec 2017, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83087
> 
> --- Comment #15 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
> (In reply to H.J. Lu from comment #14)
> > (In reply to Markus Trippelsdorf from comment #13)
> > > (In reply to Jakub Jelinek from comment #12)
> > > > 1.4% increase is not negligible if it is forced on all users without easy
> > > > option to disable it when they don't need/want it.
> > > 
> > > To be fair, it can be easily disabled with --disable-cet.
> > > The question is, if it should be enabled by default.
> > 
> > We want to enable Intel CET by default in GCC and glibc, which can be
> > disabled by --disable-cet.
> 
> Do you have any performance numbers? What is the impact of all these
> NOPs on non CET CPUs?

I'm also still missing answers to my questions at the Cauldron:

 - statistic about finding ENDBR + "required code" sequence in binaries
   vs. finding "required code"
 - statistics about finding NOTRACK + call and the ability to disable
   the NOTRACK feature in HW to remove this loophole.

ENDBR is 4 bytes, NOTRACK is just one byte (3e) so that looks very
susceptible to exploitation.  Regular code shouldn't need NOTRACK
so the HW should offer a way to disable it (track the jump anyway
or raise an exception), otherwise the feature looks pretty useless.
The risk of finding random ENDBR is there but due to its size
(and choice of bytes?) more minimal.