[llvm] [LFI][AArch64] Add PAC support (PR #207915)

[Zachary Yedidia via llvm-commits]

================
@@ -296,8 +296,13 @@ before moving it back into ``sp`` with a safe ``add``.
 Link register modification
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When the link register is modified, we write the modified value to a
-temporary, before loading it back into ``x30`` with a safe ``add``.
+When the link register is modified, it is guarded back into the sandbox with a
+safe ``add x30, x27, w30, uxtw``. This guard is deferred until the next
+control-flow instruction rather than emitted immediately after the
+modification. Deferral keeps a signed return address intact so that a following
+authentication instruction (such as ``autiasp``) can run before the guard,
+which would otherwise destroy the pointer authentication signature. See
+`Pointer Authentication Code (PAC) support`_.
----------------
zyedidia wrote:

I think your analysis is mostly accurate, but the failure mode in the current approach would not be an authentication failure. The rewriter currently always inserts an LR mask at the end of a basic block that modifies LR. As a result, for an input program that loads LR, branches somewhere, and then authenticates it, the mask that gets inserted before the branch will simply overwrite the PAC bits, causing the later authentication to become a no-op. In theory, as long as the branch is direct the verifier could have a more sophisticated analysis that could allow placing the mask in a separate basic block (the verifier would check that the mask occurs on all possible paths), but I'm not sure that engineering for this is relevant until there is an actual use-case.

The broader solution to this type of problem is to start relying on a stronger CFI mechanism that doesn't require masking return/code pointers. For example, using SafeStack for backward edge and table-based or label-based CFI for forward edge (or some hybrid mechanism). These techniques have less compatibility with existing code than the current approach, but may still be broadly usable.

https://github.com/llvm/llvm-project/pull/207915