Re: [PATCH v11 1/7] typeinfo: Introduce KCFI typeinfo mangling API

[Kees Cook <kees@kernel.org>]

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.

-Kees

-- 
Kees Cook