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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
