> > We track the unstable feature(s) at > https://github.com/Rust-for-Linux/linux/issues/2 (I just moved this > one there since it is close to ready, but it was in #355 previously, > and cleaned things up a bit). Sorry about that, I should've done this already. In addition to the link you added above, here's a tracking issue for KCFI support for Rust: https://github.com/rust-lang/rust/issues/123479 There are still a few unresolved questions that I'd like to hear from you as you experiment with it, which the tl,dr. is: KCFI support for Rust shares most of its implementation with the CFI support, with some key differences: KCFI performs type tests differently and are implemented as different LLVM passes than CFI to not require LTO. KCFI has the limitation that a function or method may have one type id assigned only. Because of limitation listed above (2), the current KCFI implementation (not CFI) does reifying of types (i.e., adds shims/trampolines for indirect calls in these cases) for: Supporting casting between function items, closures, and Fn trait objects. Supporting methods being cast as function pointers. There may be possible costs of these added levels of indirections for KCFI for cache coherence/locality and performance, possible introduction of gadgets or KCFI bypasses, and increased artifact/binary sizes, which haven't been looked at yet, and I'm honestly not super happy about it (but it's better than the original proposal of adding shims/trampolines to every virtual call in the Rust compiler), so I'd be interested in any performance results or regressions you may have while experimenting with it, more specifically: Linux Kernel without KCFI vs Linux Kernel with KCFI vs Linux Kernel with Rust and KCFI, possibly isolated to the code of a driver that has an implementation in C vs an alternative implementation in Rust.
