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.
