[sysvabi64] document requirement for bti c in more detail

[nsz-arm]

the text currently has

"An executable or shared library that supports BTI must have a bti c instruction at the start of any entry that might be called indirectly."

but it's not clear if compilers should consider potential linker inserted veneers with indirect call/jump or if the linker should ensure that when a veneer is inserted it does not break bti compatibility.

(gcc+ld.bfd made different choice than llvm+lld)

see discussion at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671

[smithp35]

Maybe worth ELF in addition to sysvabi as this would also affect bare-metal (pac-bti M) which would presumably also be affected if GCC was not emitting BTIs for functions that could require a stub.

My reading was that without a specific exception for linker created veneers/stubs code-generators had to assume that one might be created and generate code as if one could be inserted. I can remember clang always generating BTI instructions as it couldn't make an assumption that an indirect branch would be generated by the linker.

I think it is to the benefit of security to have fewer BTIs so having linker stubs that are BTI aware is an overall improvement so it is likely the preferred direction of travel. I think it is worth a wider discussion as IMO to make GCC behaviour not a bug, we would have to add a specific requirement for linkers to be BTI aware in the ABI and no such requirement exists at the moment.

Assuming we can get the agreement to add to the requirement, I'm thinking if there is anything that needs doing about transition. As I understand it:

• GCC objects + (BFD prior to 106671 or LLD) are at risk of an indirect jump to a non-BTI compatible function.
• Clang objects always have BTI so are safe with either linker.
  I'm not sure if there is anything we can do as a BTI aware linker will work with both. The only failing case is an older linker with objects with non-BTI compatible functions.

The other thing we may want to address is whether there is any additional marking we can do to make your optimisation possible without disassembling the binary.