HWASAN detects against spatial and temporal memory errors; i.e. you have a pointer to memory that gets freed, and use it again (temporal), or a stack overrun into nearby memory (spatial).

Pointer Authentication is used to sign pointers to give them a kind of provenance, but it's largely used to protect against code reuse/control flow attacks (ROP is much more difficult because you cannot re-use arbitrary gadgets in the executable; the stack pointer is part of the pointer signature, so screwing with it results in termination if the signature doesn't check out.)

They are both complimentary; you could use them both. HWASAN (using memory tagging) and pointer authentication use the unused upper bits of a virtual address to store their metadata. They are compatible, but this does mean combining them reduces the overall amount of bits available for pointer signatures.

There is a recent paper discussing the use of pointer authentication to build more advanced defenses; it looks like it's worth a read, and some comparisons (including HWASAN) are available in Section 8: https://www.usenix.org/system/files/sec19fall_liljestrand_pr...

Hardware Address Sanitizer is intended to protect against memory corruption in general, while pointer authentication helps ensure code flow integrity. (And I think it's mutually incompatible with the implementation that iOS uses because they both use TBI).

They can be compatible. Memory tagging does use the TBI bits. Pointer authentication uses an arbitrary number of bits, and the kernel configures the width and whether the TBI bits are preserved. So you can use both, it just costs you 8 bits of signature.

Moreover, this can be configured independently for code and data pointers. iOS turns off TBI on code pointers to get 8 more bits of signature. That's not a problem for memory tagging because memory tagging isn't particularly useful for code pointers anyway.

> Moreover, this can be configured independently for code and data pointers. iOS turns off TBI on code pointers to get 8 more bits of signature.

Ooh, this is cool. Does iOS currently use different signature sizes? Can I write an application that uses the top bits of data pointers?

> Does iOS currently use different signature sizes?

Code and data live in the same address space, and the address-space needs of the system are the main input to the basic signature width, so the basic signatures widths are currently the same, and the only difference is TBI.

You could imagine a system where code was always loaded into a restricted subset of the address space and so code pointers could use wider signatures.

> Can I write an application that uses the top bits of data pointers?

Apple's ABIs actually consider the top 8 bits of data pointers to be outside the addressable range on all its 64-bit targets, including x86_64. ARM64 TBI just means that you don't need to explicitly mask off those bits before doing loads and stores. But there are caveats:

- ARMv8.5 memory tagging uses bits 56-59, so you should probably stick to just the top four bits in case Apple ever uses memory tagging.

- IIRC the first ARM64 iOS release didn't enable TBI, so if your deployment target goes really far back, you do still need to mask.

- The ABI for pointers expects those bits to be clear on normal ABI boundaries. This means you need to mask before handing pointers off to other code; on the upside, however, you don't need to worry about those bits being set when you receive a pointer.