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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to