[compiler-rt] [libcxxabi] [libunwind] [runtimes][PAC] Harden unwinding when possible (#138571) (PR #143230)

[Anatoly Trosinenko via cfe-commits]

https://github.com/atrosinenko commented:

I have tested this patch on Linux with `aarch64-linux-pauthtest` triple and custom-built sysroot, here are the results.

In my setup, the tests pass on the following modified branch: https://github.com/atrosinenko/llvm-project/commits/pointer-authenticated-unwinding-fix1/. It is based on https://github.com/kovdan01/llvm-project/commits/pointer-authenticated-unwinding-fix0/ with the following changes:
* Currently, several parts of the patch are only enabled on Apple targets. For testing purposes, I unconditionally enabled parts of this patch guarded by `defined(__APPLE__)`.
* It turned out that `__has_feature(ptrauth_qualifier)` does not work in mainline, so I replaced it with `__has_feature(ptrauth_intrinsics)`. I expect the correct solution proposed by @kovdan01 (replacing with `__has_extension(ptrauth_qualifier)`) to behave identically.
* The change to `compiler-rt/lib/profile/InstrProfilingValue.c` seems to be unrelated to libunwind
* The most meaningful change is updating signing schemas is several places - see inline comments. Additionally, I had to update a few other places that I cannot add inline comments to
  - in `Registers_arm64::getRegister` and `Registers_arm64::setRegister`, replace direct references to `_registers.__pc` with calls to `getIP()` and `setIP()`, correspondingly
  - disable the existing pauth-related logic in `DwarfInstructions<A, R>::stepWithDwarf`

The fact I'm worried about is whether implicit signing and authentication on accesses to `__ptrauth`-qualified fields may introduce signing or authentication oracles usable by an attacker, since many values stored to these fields are initially non-signed. This is possibly mitigated by the fact that all these fields use address diversity with distinct integer discriminators and/or the original values are taken from read-only memory. On the other hand, discriminator computation, auth / sign intrinsic and load / store to memory are currently three separate operations when accessing a `__ptrauth`-qualified field, thus spilling of intermediate values to the stack is possible. Furthermore, even if the non-signed value originates from a read-only memory, this is not expressed in LLVM IR terms, thus the optimization pipeline may transform sensitive instruction sequences in an unsafe way.

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