Conversation

This Tweet was deleted by the Tweet author. Learn more
Replying to and
It's only required to work within objects. I also don't think typical uses of pointer authentication will impact anything other than pointers not directly available to C without compiler intrinsics (return addresses) and function pointers. It won't be used for most regular data.
1
Verifying that pointers passed to free and realloc were created by malloc doesn't seem particularly useful. Maybe I'm misunderstanding how it would be used. I also don't find this to be a particularly compelling feature. ARMv8.5 MTE (memory tagging) is a great feature though.
2
1
SPARC is considered too niche, so the feature doesn't get attention from security engineers working in more mainstream OSes even if they support SPARC. It also doesn't get much attention from security researchers. It's extremely compelling for both debugging and security though.
1
Using it in malloc is cheap and it can provide nice deterministic guarantees rather than just being a weak probabilistic mitigation via entirely random tags. Catching linear overflows beyond allocations is easily guaranteed and catching UAF within N reuse cycles is quite doable.
1
The issue with PAC is it's *only* a weak probabilistic mitigation, and they implemented that *instead* of providing a strong deterministic mitigation. Intel CET is very comparable to ARMv8 PAC + BTI but it's going to be providing a hardware-based shadow stack, which is way nicer.
1
A nice thing about PAC is that you could in theory use it elsewhere, but it's a very weak mitigation and isn't even close to free in terms of performance. Fine-grained CFI is a way better way to spend those cycles for function pointers, and hw accel for it would have been nice...