asl wrote: > 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.
I think we will need to revise / reinvestigate this issue after this PR and see if we can move forward with more robust approach. 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
