[llvm] [AArch64][PAC] Introduce AArch64::PAC pseudo instruction (PR #146488)

[Anatoly Trosinenko via llvm-commits]

atrosinenko wrote:

@pcc To clarify things a bit further, I feel like PAC pseudo is quite different from AUT and AUTPAC pseudos. When a pseudo instruction is expanded into an authentication (and possibly something else afterwards), a significant overhead is possible due to checking if the authentication succeeded - in some cases this is important if the CPU does not implement FEAT_FPAC - furthermore, this check can be inserted automatically. On the other hand, while it is crucial to only provide safe values for PAC pseudo to sign, there are not much things AsmPrinter can do automatically for a standalone PAC.

As far as I can see, it should be rather straightforward to conditionalize this logic as long as there is a condition: I should be able to provide a `Predicate` to tablegen patterns the same way it is currently done to choose one of `AUTH_TCRETURN*` flavors. Then the tablegenerated instruction selector would either select one of real `PAC[ID][AB]` instructions (whose discriminator operand would be naturally computed by `MOVKXi` when needed and no custom inserter is required) or `PAC` pseudo instruction (which would be further postprocessed by absorbing the `MOVKXi`, if any) depending on the predicate.

The problem is that there doesn't seem to be a clear predicate to use: we want to choose whether to protect against the threat X or save Y instructions of overhead depending on the condition P. In case of AUTx16x17 vs. AUTxMxN choice, X is "a sensitive value can be stored in an unsafe register" and Y is increasing register pressure, etc. Then P can obviously be chosen as "x16/x17 are safer that other general-purpose registers", as otherwise all registers are equally safe (or equally unsafe), thus there is no threat X at all, but the cost Y of the mitigation is still non-zero.

In case of this PR, on the other hand, Y is known (adding at most two simple instructions per single `PAC[ID][AB]`) and threat X is "the discriminator value can be spilled to the (unsafe) stack". Here, there is no clear condition when the threat does not exist at all: we cannot easily express whether the discriminator value would be spilled and the stack (just as any other memory under Pointer Authentication threat model) is always unsafe. Thus, this is more of an arbitrary decision to be made by the end user: whether we want a bit more security or a bit smaller code.

I think the overhead is quite small, so we could turn this security feature on unconditionally without the chances to accidentally forget to opt-in. On the other hand, if decreasing the code-size overhead is worth increasing the "implementation overhead", then it should be feasible to expose a predicate to the tablegenerated patterns (for example "enable the protection as long as the user have not opted-out explicitly").

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