[llvm] [AArch64][PAC] Combine signing with address materialization (PR #130809)

[Oliver Hunt via llvm-commits]

https://github.com/ojhunt commented:

Semantically, this looks reasonable to me, but I'm not really a back end/isel expert so I think @ahmedbougacha needs to look at this.

One thing I'd like to see is a test case that tries to induce an oracle using the intrinsics in C, something akin to

```c
   void* f1(void *p) {
      void* authed = __ptrauth_auth(p, ....);
      __asm__(""); // may be a sufficient barrier?
      return __ptrauth_sign(authed, ...);
   }
   
   void* f2(void *p) {
      void* authed = __ptrauth_auth(p, ....);
      __asm__(""::"r"(authed)); // theoretically does not spill so no oracle
      return __ptrauth_sign(authed, ...);
   }
   
   void* f3(void *p) {
      void* authed = __ptrauth_auth(p, ....);
      __asm__(""::"m"(authed)); // theoretically does spill so would be an oracle, what should happen?
      return __ptrauth_sign(authed, ...);
   }
```

In an ideal world - out of scope for this change - I think we'd like to error out if we ever see a read from memory into an unauthenticated sign, or a spill and subsequent read of an authenticated value. Doing this robustly probably requires recording that a value was authenticated, then in clang producing a warning or error if a developer does something that forces post-auth store to memory, and for llvm/implicitly authed values increasing the keep-in-register priority for those values, and finally if they still end up being spilled giving them a custom auth schema and signing them on spill.

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