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

[Scott Constable via cfe-commits]

scottconstable wrote:

> Sorry, what I meant was we should be looking only at the number of return (with void being zero, and everything else being one) and parameters from the function declaration/definition and shouldn't be looking at the parameters' type layout (i.e., size), and how and what registers are used to pass them (i.e., we shouldn't mention or reference registers or assembly code at all in the implementation and documentation). The implementation should be completely ABI and architecture agnostic. Does it make sense?

I think that the aspiration to be "completely ABI and architecture agnostic" is irreconcilable with the security objective to prevent a register that is dead at a call site from becoming live at a hash-collided call target.

Your point about returns is interesting. AFAIK most x86 Linux kernels (including Ubuntu kernels) are being compiled with `-fzero-call-used-regs=used-gpr`, which in most cases should prevent a dead return register (`RAX`) from becoming live at a call site when the call site expects a return value. I can think of one corner case, but I'm not sure how much of a concern it would be in practice. Suppose that `int (*)(int)` collides with `void (*)(int)` and this allows a function `f` of the former type to call a function `g` of the latter type. Suppose further that `RAX` dies when `f` calls `g` and `g` does not touch `RAX` at all, which means that `-fzero-call-used-regs=used-gpr` will have no effect on `RAX` in `g`. Then when `g` returns to `f`, the stale value that `f` had left in `RAX` will become live and might be used for something malicious.

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