[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:

Sorry you are right I got that mixed up. I went back and looked at my notes about PAC with LFI from when I was thinking about this in more depth, and at the time I noted down a few alternatives but I think the approach we have here is probably the best, even though the issue that you raised is a problem that could come up for hand-written assembly. I think the most viable alternative would be to release the invariant that `x30` contains a code pointer and allow it to instead contain anything, and then rewrite return instructions to `add x28, x27, w30, uxtw; ret x28`. One downside of this is that we introduce a guard for leaf functions that don't otherwise need it, and the sequence for a runtime call may need to be reworked slightly.

> Other types of CFI exist, yes, but I inferred that the idea here was to preserve the semantics of the source program whilst adding LFI sandboxing. Was I mistaken?

No you're correct, and the other mechanisms I was referring to tend to have compatibility issues with hand-written assembly anyway so the point is relatively moot.

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