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?
