[lld] [LLD] Add flag to force PLT entries to have a BTI (PR #168365)

[Peter Smith via llvm-commits]

smithp35 wrote:

My thoughts on security.

The PLT sequence is itself an indirect jump, so a target function defined in the same executable/shared-library that the PLT entry is transferring control to must have a BTI compatible instruction. If an attacker has an arbitrary write primitive then they could just target the function in question directly. Adding a BTI is not a significant loss in that case.

If the PLT entry is targeting another executable/shared-library then the destination may not have a BTI compatible instruction (BTI property is per shared-object not per program), and with lazy loading the attacker may not know the address of the destination (but they do know the address of the PLT). Not putting a BTI at the start of the PLT entry for "imported" symbols does offer some additional protection.

It is difficult to quantify how much effect on security this would have in practice. Given that on most systems using BTI, the whole program (executable and shared-objects) are likely to have BTI enabled, I suspect not much.

One thing that could be measured is whether the addition of an additional BTI instruction in all PLT sequences has any measurable affect on performance. My expectation is that this will be lost in the noise of an out-of-order implementation, but on the simplest in-order implementations like the A320 it may be noticeable if loops are involved.

Another factor to consider is how much tool implementation detail BOLT is willing to depend on. For example GNU ld happens to put BTI at the start of each PLT entry, but are there any guarantees that will continue? Perhaps this should be written into the ELF conventions https://github.com/ARM-software/abi-aa/tree/main/baabielf64 if BOLT is considering this ABI.

https://github.com/llvm/llvm-project/pull/168365