[Bug target/102953] Improvements to CET-IBT and ENDBR generation

["andrew.cooper3 at citrix dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #20 from Andrew Cooper <andrew.cooper3 at citrix dot com> ---
(In reply to H.J. Lu from comment #19)
> (In reply to Andrew Cooper from comment #17)
> > I think I've found a bug in the -fcf-check-attribute implementation.
> 
> Please try the v5 patch.

Thanks.  That does fix the issue.

>  BTW, do you have a testcase to show how
> -fcf-check-attribute=yes is used?

So, this was something I was going to leave until I'd got CET-IBT working, so
as to have time to consider all parts before proposing improvements.

I don't have a usecase for -fcf-check-attribute=yes, because it is almost
totally redundant with regular -fcf-protection in the first place.

When you are are applying control flow checks, every function is either checked
or not checked.  But GCC currently has a 3-way model of {unknown, explicit yes,
explicit no} on which it builds its typechecking.

Furthermore, -mmanual-endbr is a gross hack which by default leaves you with a
broken binary.

If I were building this from scratch, I'd not have -mmanual-endbr or
-fcf-check-attribute at all, because they're exposing complexity which ought
not to exist.

I get why the default for -fcf-protection=branch puts an ENDBR* instruction
everywhere.  It is the quick, easy and non-invasive way to make libraries
compatible with CET, which is a net improvement, even if not ideal.

The ideal way, and definitely future work, is for GCC to calculate the minimum
set of required ENDBR*.  At a guess, all non-local symbols (except those LTO
can determine are not publicly visible), and any local symbols used by function
pointers.

What I'm trying to do is a stopgap in the middle.  No ENDBR*'s by default, but
have the compiler tell me where I've got function pointers to a non-ENDBR'd
function, so when the result compiles, it stands a reasonable chance of
functioning correctly.

Personally, I'd suggest having these as sub-modes of -fcf-protection=branch,
instead of exposing all the internals on the command line.