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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
