Pointer Authentication of ARM

Giulia Ferri said:

1) why do you need XPAC * instruction? Is not it a problem for security in case of an attack? If so, is it possible to trap only the use of this instruction for a certain
exception level?

Computer attacks are becoming more sophisticated. Examples of this are exploit mechanisms such as the use of gadgets in Return-Orientated-Programming (ROP) and Jump-Orientated-Programming (JOP). To mitigate against such exploits, Armv8.3-A introduces a feature that authenticates the contents of a register before it is used as the address for an indirect branch or data reference.  HCR_EL2, SCR_EL3 System register controls that trap accesses to Pointer authentication functionality: Traps to EL2/3 any use of an enabled Pointer authentication instruction.

Giulia Ferri said:

2) When an authentication fails, a translation faults occurs. Is it possible to know, from the values of registers, that this is given by a failed authentication and not for another reason?

New instructions are added which can be used to:

* Insert a PAC into a pointer
* Strip a PAC from a pointer
* Authenticate strip a PAC from a pointer

If authentication succeeds, the code is removed, yielding the original pointer.
If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.

Giulia Ferri said:

3) What types of attacks PAC can block and which ones do not?

Return-Orientated-Programming (ROP) and Jump-Orientated-Programming (JOP)

Giulia Ferri said:

4) Which ARM processors implement PAC?

arm processors which support ARMv8.3-PAuth, Pointer Authentication, currently there's no processor support ARMv8.3-PAuth.

Giulia Ferri said:

1) why do you need XPAC * instruction? Is not it a problem for security in case of an attack? If so, is it possible to trap only the use of this instruction for a certain
exception level?

The ARMv8.3 pointer authentication extension adds functionality to detect modification of pointer values, mitigating certain 
classes of attack such as stack smashing, Return-Orientated-Programming (ROP) and Jump-Orientated-Programming (JOP). 
System register HCR_EL2/SCR_EL3 controls that trap accesses to Pointer authentication functionality: Traps to EL2/3 any use of an enabled Pointer
authentication instruction 

Giulia Ferri said:

2) When an authentication fails, a translation faults occurs. Is it possible to know, from the values of registers, that this is given by a failed authentication and not for another reason?

New instructions are added which can be used to:

* Insert a PAC into a pointer
* Strip a PAC from a pointer
* Authenticate strip a PAC from a pointer

If authentication succeeds, the code is removed, yielding the original pointer.
If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.

Giulia Ferri said:

3) What types of attacks PAC can block and which ones do not?

making stack smashing, Return-Orientated-Programming (ROP) and Jump-Orientated-Programming (JOP) hard

Giulia Ferri said:

4) Which ARM processors implement PAC?

Next generation processor that support armv8.3, PAuth, currently there's no such processor.

Thank you for your answer.

some things are not clear to me yet.
for question 1, I would like to know why the instruction for strip a PAC from a pointer is designed. In which cases is it useful?
for question 2, I would like to know more specifically if and how it is possible to understand that the translation fault is due to the failure of authentication by reading the registers. I would like to handle the fault only if the translation fault is caused by the failure of the authentication of a PAC.

Hi Giulia,

1. Library code performing stack unwinding may need to use XPAC* rather than attempting authentication and/or acquiring
  the PAC masks via ptrace. 

And kernel perf will use xpac* when unwinding, here's an example:

https://patchwork.kernel.org/patch/10077257/

2. If the check fails, the second-top and third-top bits of the extension bits in the pointer authentication code field are corrupted to ensure that accessing the address will give a translation fault. Can check this error bits of the fault address if identify if it's a pac fault.