[llvm-branch-commits] [llvm] [BOLT] Gadget scanner: Detect address materialization and arithmetics (PR #132540)

Kristof Beyls via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Thu Apr 3 02:43:24 PDT 2025


================
@@ -587,6 +587,22 @@ class MCPlusBuilder {
     return getNoRegister();
   }
 
+  virtual MCPhysReg getSafelyMaterializedAddressReg(const MCInst &Inst) const {
+    llvm_unreachable("not implemented");
+    return getNoRegister();
+  }
----------------
kbeyls wrote:

Thanks, it's probably still a bit complicated, but with the comment it's possible for a reader to dig in and understand what the assumed threat model is.

On the comment
```
  /// Returns the register containing an address which is safely materialized
  /// under Pointer Authentication threat model, or NoRegister otherwise.
  ///
  /// The produced address should not be attacker-controlled, assuming an
  /// attacker is able to modify any writable memory, but not executable code
  /// (as it should be W^X).
```
I think that the first sentence could be improved a little bit by also explicitly stating that it is the register materialized by `Inst` (the first argument to the function). Maybe to something like the following?
```
Returns the register `Inst` writes to if:
1. the register is a materialized address, and
2. the register has been materialized safely, i.e. cannot be attacker-controlled, under the Pointer Authentication threat model.
If the instruction does not write to any register satisfying the above 2 conditions, NoRegister is returned.

The Pointer Authentication threat model assumes code is not writeable (W^X), but data memory may be written to by an attacker ("is attracker-controlled")
```

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


More information about the llvm-branch-commits mailing list