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. Martin
