scottconstable wrote: > > Second, this scheme reduces the expected number of hash collisions within > > each arity, compared against the expected number of collisions (0.01383765) > > for the 32-bit hashing scheme that includes all arities. The table below > > shows the expected number of collisions for each arity, given the number of > > unique indirect callable function types within that arity in the same > > Ubuntu 24.04 server kernel discussed above. > > The collisions vary a lot with different number of function types. It looks > to me more smooth if we use 2 bits to distinguish 4 cases: 1, 2, 3 and 0 or > others.
I re-ran the numbers with a 30-bit hash and 2-bit arity, and you are correct that the distribution of expected collisions is more smooth: | Arity | Unique Indirect Callable Function Types | Number of Expected Collisions | | ----- | --------------------------- | --------------------------------- | | 0 or >3 | 2089 | 0.00201654 | | 1 | 2492 | 0.00287330 | | 2 | 3775 | 0.00660789 | | 3 | 2547 | 0.00300181 | However, a 2-bit arity would undermine what is arguably the more desirable property: > This scheme enhances security in two ways. First, it prevents a j-arity > function pointer from being used to call a k-arity function, unless j=k. The > current 32-bit kCFI hash does not prevent, for example, a 2-arity fptr from > calling a 3-arity target if the kCFI hashes collide. If this were to happen, > then potentially malicious stale/dead data in RDX at the call site could > suddenly become live as the third parameter at the call target. For example, if the 30-bit hash of a 0-arity function type collides with the 30-bit hash of the type of a 4-arity function type, then the `RDI`, `RSI`, `RDX`, and `RCX` registers that die when calling a function of the 0-arity type will unexpectedly become live if a COP attack redirects the call to a function of the 4-arity type. Therefore, I believe that the 29-bit hash and 3-bit arity offers a more favorable security posture. 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
