[clang] [llvm] [X86] Enhance kCFI type IDs with a 3-bit arity indicator. (PR #117121)

[Matthew Maurer via cfe-commits]

maurer wrote:

I'm not sure I buy the argument that cross-arity functions are significantly more exploitable than same-arity mismatches.

Restating your argument to make sure I've understood it correctly: When an attacker swaps in a function pointer of higher arity, a dead variable (or even a live one expected to be restored afterwards), may be used improperly by the function. The attacker is more likely to be able to control this than other parameters. (This last part is the piece that I don't see the justification for.)

However, this argument applies to *every* argument consumed by a function - each is as likely to be attacker controlled as the contents of a dead register, and if the function pointer thinks it's getting a value of a different type (e.g. believes it's getting a pointer, gets an attacker controlled flags value). This seems to be an argument that higher arity functions are more likely to be exploitable because it's more likely that the attacker controls at least one of their argument.

Additionally, the increased likelihood of exploitability of a mismatch needs to be quite high to justify what you're describing. Let `p` be the probability that a type mismatch with matching arity is exploitable, and `q` be the probability that a type mismatch with an arity change is exploitable. Let X be the base collision rate. Then the old scheme has an exploitability rate of: `0.01375771 * (p * 0.25 + q * 0.75)` and the new one has a rate of `0.02660650 * p`. Setting equal and reducing to find the breakeven point,
```
0.022575 p = 0.010275 q
2.197 p = q
```

So if you want to claim this is to increase the strength of the scheme, you need to argue that an attacker is more than twice as likely to be able to exploit an arity mismatched function as a type mismatched one, which seems like a bit of a stretch - attackers often have direct control of intentionally passed arguments...

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