[Bug c/102953] New: 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

            Bug ID: 102953
           Summary: Improvements to CET-IBT and ENDBR generation
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

Hello,

With CET-IBT, ENDBR{32,64} instructions are used to mark legitimate forward
edges for indirect branches.

GCC can generate a CET-IBT binary with -fcf-protection, but the default
behaviour is to generate ENDBR instructions for every function.  This creates
more "legal" forward edges than necessary in the eyes of CET-IBT.

https://godbolt.org/z/M15rjMb4G is almost excellent, but it would be far more
helpful if all functions were implicitly nocf_check, so this example produces a
diagnostic.  That way, GCC can point out all functions used by function
pointers, rather than the result compiling and failing to be CET-IBT
compatible.

This on its own would be enough to let embedded projects minimise their ENDBR*
count while having some compiler assistance while doing so.


More generally, a lot of common cases (e.g. Linux) could be computed
automatically.  Drivers filling in ops structures typically refer to local
symbols, so these defaulting to cf_check would be an improvement still.  This
would leave only global symbols needing explicit cf_check.  (Maybe LTO could
even figure out the global symbols cases correctly?)

Finally, one minor code generation improvement.  When GCC emits a direct
call/jmp to an ENDBR'd symbol, it can actually use sym+4 as an optimisation to
skip the ENDBR instruction (not needed for direct call/jmp's) and save on
decode bandwidth.