[clang] [llvm] [AArch64][PAC] Sign block addresses used in indirectbr. (PR #97647)

Ahmed Bougacha via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 17 11:08:57 PDT 2024


ahmedbougacha wrote:

> The difference should be not be signed IMO as stated above.

We discussed this in the sync-up, but for the record I don't think we can get away with not signing and nothing else.  It defeats the purpose of signing these in the first place:  an arbitrary write becomes a branch to an arbitrary destination.

One alternative would be to sign the difference, though we would want to have a specific way for people to write it to make it predictable (single expression, 64-bit result;  maybe explicitly as a builtin).  Doesn't help existing code, but there's already a high adoption cost for all of these ptrauth changes, this seems almost trivial in comparison ;)

A radically different solution could be to lower the blockaddresses without signing, then turn the goto into a checked switch.  That allows substitution, but that's already the case for signed blockaddresses.
That would easily work with real block addresses, but the switch would look nasty.  If we used some dense numbering of the address-taken blocks, and lowered `blockaddress()` into that number, then the switch becomes a simple jump table, and the only check needed is a range check.  So we'd pretty much end up with the "hardened" jump-table from #97666.
Either way this could still be relatively expensive, and pushes the cost from address materialization to dispatch, which seems like the worst tradeoff for anyone using indirect goto..  So I'm not sure I would want to adopt this for MachO, but I'm happy to help and review if folks want to implement this.
Thankfully this isn't ABI visible (beyond the usual problems with code looking at the values) so either way we can replace this entirely in the future.

In the meantime, for this PR, I'll look into more actionable errors for the unencodable constant expressions, and the single-expression difference, when we can diagnose it.  But at the end of the day they'll still be errors.

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


More information about the cfe-commits mailing list