News for hackers. Stuff that matters.
Re:ARM Pointer Authentication by haberman on Sunday June 04, 2017 @03:01AM (#14480222)
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.

Re:ARM Pointer Authentication by im3w1l on Sunday June 04, 2017 @03:11AM (#14480245)
> 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?

Re:ARM Pointer Authentication by fanf2 on Sunday June 04, 2017 @06:09AM (#14480641)
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.