[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