On Tue, May 12, 2026 at 1:35 AM Peter Zijlstra <[email protected]> wrote: > > On Tue, May 12, 2026 at 10:13:42AM +0200, Martin Uecker wrote: > > Am Montag, dem 11.05.2026 um 13:41 -0700 schrieb Kees Cook: > > > On Mon, May 11, 2026 at 10:08:06PM +0200, Martin Uecker wrote: > > > > Am Montag, dem 11.05.2026 um 12:48 -0700 schrieb Kees Cook: > > > > > To support the KCFI typeid and future type-based allocators, which > > > > > need > > > > > to convert unique types into unique 32-bit values, add a mangling > > > > > system > > > > > based on the Itanium C++ mangling ABI, adapted for C types. Introduce > > > > > __builtin_typeinfo_hash for the hash, and __builtin_typeinfo_name for > > > > > testing and debugging (to see the human-readable mangling form). Add > > > > > tests for typeinfo validation and error handling. > > > > > > > > > > This ABI needs to match what is used by LLVM Rust (which matches the > > > > > Clang > > > > > ABI) so that KCFI can work on mixed GCC with LLVM-Rust kernel builds. > > > > > Instead of inventing a new ABI, all use the existing Itanium C++ > > > > > mangling > > > > > which matches KCFI's needs. > > > > > > > > > > An important aspect of the C++ typeinfo behavior that is retained here > > > > > is that typedefs are treated as pass-through except when the > > > > > underlying > > > > > type lacks a tag (i.e. anonymous struct, union, or enum). This > > > > > provides a > > > > > distinction between those typedefs and typedefs used to provide > > > > > _aliases_ > > > > > (u8, uint16_t). > > > > > > > > > > In the future, an additional "strict mode" builtin helper pair could > > > > > also be added to follow strict ISO C type equivalency instead of the > > > > > existing typeinfo used here, but that is out of scope for this patch. > > > > > > > > Note that ISO C would require *less* strict rules, so the current > > > > mangling would reject compliant code. > > > > > > > > These ABI issues were recently discussed also on the rust side. > > > > > > > > I now worry that it might actually be a mistake to enshrine > > > > the wrong rules into the ABI, creating language interoperability > > > > issues which might then plague us for years. > > > > > > Well, this matches what we've already created (and have been using for > > > years) on the Clang side. I'm happy to rename this to whatever you want > > > to avoid confusion, but I don't really want to change the rules of this > > > ABI. I'd rather get it working as-is, and then if we want to make > > > mangling changes, do that simultaneously between GCC and Clang. > > > > > > And this is totally do-able, e.g. I've already created the transition > > > path on the Clang side for changing the hashing algo. For KCFI, we don't > > > need to worry about cross-ABI-version compatibility: the kernel is built > > > as one binary, effectively. We just need to worry about GCC/Clang > > > compatibilities given the Rust side of things. > > > > I think with the generic names (__builtin_typeinfo_hash) users would > > start to use this for all kinds of things (because it is useful more > > genrally!) and then run quickly into trouble. > > > > So I think one should either have less generic names, or probably better, > > some kind of ABI argument. An ideally, we would then provide a > > standard-compliant and future-proof mode out-of-the-box (I can help > > with this). If the kernel then opts into a stricter mode this would > > not be problematic. > > From the kernel PoV, GCC has been lagging behind horribly on this, and > the sooner this gets merged the better. If Kees were to rename these > intrinsics to __builtin_kcfi_*(), to make them really specific and free > up the namespace for the more generic one that should be good enough, > no?
But the GCC PoV is that this was merged into LLVM without taking into account C correctly is a bigger issue. Really LLVM should have fixed this up years ago but didn't. Yes this has been raised to the LLVM community as being broken but it seems like it has been dismissed. Linux community has been dismissing this issue since it has been raised too. My suggestion would be to name these builtins as __builtin_linux_abi_kcfi_* to signify this was a mistake in the linux ABI. Thanks, Andrea
