[llvm-branch-commits] [llvm] [BOLT] Gadget scanner: detect signing oracles (PR #134146)

[Kristof Beyls via llvm-branch-commits]

================
@@ -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 *>>
----------------
kbeyls wrote:

Off the top of my head, for the following example code (which probably wouldn't be produced by any currently existing compiler, but that could be written by hand in assembly?), I guess that's a single basic block for which `getAuthCheckedReg` would have to return 2 pairs?:
```
bb1:
    autda x0, x1
    autda x2, x3
    ldr xzr, [x0]
    ldr xzr, [x2]
```

I'm OK with not handling this case in this PR, but then maybe there should be a test case with a basic block similar to the above to show how BOLT will either produce an error message or otherwise fails to handle this case?

In any case, this PR should probably also document in https://github.com/llvm/llvm-project/blob/main/bolt/docs/BinaryAnalysis.md what the user of this analysis can expect in terms of false positives and true negatives.

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