p < q is only defined if they point into the same thing, I think?
Conversation
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
I believe people are working on making malloc produce authenticated pointers.
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
Each allocation has a different tag, preventing heap overflows from corrupting nearby allocations. Mitigates common browser exploitation technique
1
It sounds like you're talking about ARMv8.5 memory tagging, not pointer authentication. I wrote up some documentation on how malloc implementations can leverage features like ARMv8.5 MTE at github.com/AndroidHardeni. I think it's a much more compelling feature than ARMv8.3 PAC.
1
1
SPARC ADI was a much earlier implementation than ARMv8.5 MTE and Solaris uses it to provide heap and stack protections. has some blog posts about those that are worth reading. ARMv8.5 MTE is huge because it brings it to far more devices and other OSes will adopt it.
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
I don't place a whole lot of value in the weak probabilistic mitigation provided by choosing random initial tags, but it's nice to have, and will catch lots of latent memory corruption bugs. It's very similar to ASan, but without the performance cost and with a lower memory cost.
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.
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...