================
@@ -622,6 +628,40 @@ class MCPlusBuilder {
return std::make_pair(getNoRegister(), getNoRegister());
}
+ /// Analyzes if a pointer is checked to be valid by the end of BB.
+ ///
+ /// It is possible for pointer authentication instructions not to terminate
+ /// the program abnormally on authentication failure and return some *invalid
+ /// pointer* instead (like it is done on AArch64 when FEAT_FPAC is not
+ /// implemented). This might be enough to crash on invalid memory access
+ /// when the pointer is later used as the destination of load/store or branch
+ /// instruction. On the other hand, when the pointer is not used right away,
+ /// it may be important for the compiler to check the address explicitly not
+ /// to introduce signing or authentication oracle.
+ ///
+ /// If this function returns a (Reg, Inst) pair, then it is known that in any
+ /// successor of BB either
+ /// * Reg is trusted, provided it was safe-to-dereference before Inst, or
+ /// * the program is terminated abnormally without introducing any signing
+ /// or authentication oracles
+ virtual std::optional<std::pair<MCPhysReg, MCInst *>>
----------------
atrosinenko wrote:
I expect all the check methods listed in
[`AArch64PointerAuth.h`](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64PointerAuth.h)
to be detected by one of these two methods. On the other hand, the
`getAuthCheckedReg(BB)` method has a closed list of hard-coded patterns to
recognize - if some other compilers or some other versions of LLVM would use
other instruction sequences, it should be possible to update this method as
appropriate. For example, LLVM used to emit an "inverted" variant of the checks
in the past: the fall-through basic block was executed on success and on
failure a jump was performed to a basic block containing a BRK instruction. Not
sure if these variants should be supported, as later the mainline backend was
aligned with the original variants of checks emitted by the prototype from the
Ahmed Bougacha's branch (these are the patterns detected in this PR), but if I
would have to support the inverted variants, the only change needed would
probably be accepting TBNZ in addition to TBZ and B.NE in addition to B.EQ.
Considering the `getAuthCheckedReg(Inst, bool)` method, it could obviously be
improved by handling store instructions (though, I doubt it would change
anything for `pauthtest` ABI). False positives (not recognizing some load
instruction as "checking") are technically possible, but I would expect them to
be due to the existing implementation of `AArch64MCPlusBuilder::mayLoad()`
which hardcodes a number of opcodes.
https://github.com/llvm/llvm-project/pull/134146
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
