This doesn't affect regular pointers. It creates a new type of pointer, a "signed pointer." You don't dereference or perform arithmetic on signed pointers. You create signed pointers with one instruction ("PAC") and decode/decrypt them into regular pointers with a different instruction ("AUT"). The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad.

All normal pointers and dereferencing continue to work the same. It only affects code that explicitly decides to use these special instructions to create/validate signed pointers. Only certain code (like the code that saves a return address to the stack) would choose to do this, for cases where an attacker is especially likely to try corrupting the pointer.

> The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad.

Hmm wouldn't a trap be better?

I expect this is to allow for code which might have an uninitialized pointer, and wants to decrypt it concurrently with other validity tests (relying on multiple issue width)

Or, the designers didn't want to add an interlock between the memory subsystems that handle traps, and the crypto subsystem that does the decryption.

How does that not mess with pointer arithmetic?

You read the pointer from memory, unbox the pointer into an integer, do arithmetic, then box it back up and write it back into memory. The pointer-as-integer stays in registers while you do arithmetic on it.

You're not supposed to do pointer arithmetic with these pointers. It's generally meant for storing pointers "at rest".

Looks like the current patch only deals with instruction pointers, but I'd assume that for data, the base pointers would have validation instructions automatically inserted before offset arithmetic is done.