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

[Jacob Bramley 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`_.
----------------
jacobbramley wrote:

Sorry, I don't think I expressed that very well. I'll try again.

There are three constraints at play here:

- The authentication (`aut*`) needs to happen _before_ the sandboxing (`add lr, x27, lr, UXTW`). Otherwise, the sandboxing operation destroys the PAC and the authentication fails.
- The sandboxing has to occur after the `x30` modification, but within the same basic block. Basically, we cannot branch away with an unchecked modification in `x30`, because the target will expect the LFI invariants to hold.
- The authentication needs to remain late, in the same basic block as the return, both for security reasons and because moving it requires a second pass and some analysis that I don't see here. _I don't know the code well, so might have missed something._

It's possible to meet all three constraints only if the modification occurs in the same basic block as the return, so an intervening branch (as in my example) creates an unsolvable situation. I think at present, it results in code that will fail authentication. It is unlikely that reasonable input programs do this, but it is not impossible, especially if the input might be malicious.

Thanks!

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