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

[Martin Uecker <ma.uecker@gmail.com>]

Am Donnerstag, dem 18.09.2025 um 11:09 -0700 schrieb Kees Cook:
> On Thu, Sep 18, 2025 at 09:20:52AM +0200, Martin Uecker wrote:
> > Am Mittwoch, dem 17.09.2025 um 17:56 +0000 schrieb Qing Zhao:
> > > Hi, 
> > > 
> > > > On Sep 13, 2025, at 19:23, Kees Cook <kees@kernel.org> wrote:
> > > > 
> > > > To support the KCFI typeid and future type-based allocators,
> > 
> > What I find problematic though is that this is not based on GNU / ISO C
> > rules but on stricter Linux kernel rules.   I think such builtin should
> > have two versions.  
> > 
> > So maybe
> > 
> > __builtin_typeinfo_hash_strict // strict
> > __builtin_typeinfo_hash_canonical // standard
> > 
> > or similar, or maybe instead have a flag argument so that we can
> > other options which may turn out to be important in the future
> > (such as ignoring  qualifiers or supporting newer languag features).
> 
> Can you send me a patch to gcc/testsuite/gcc.dg/builtin-typeinfo.c
> that shows what differences you mean? 

I can look at this in the next days.

> Because AFAICT, this C version
> matches the C++ typeinfo implementation. 

> There isn't a need for these
> hashes to be comparable in a way that they could be used to, for
> example, reimplement __builtin_types_compatible_p. It's called
> "typeinfo" and that has a specific meaning currently...

I would want the hashes for types which are compatible
according to ISO C to be identical. 

What I want avoid that this is used to implement some
run-time type checking (which is what KCFI does) and the run-time
check can fail even when a compile-time check according to the
usual rules of the language passes.  Even if this ok for the
Linux kernel, I think this would be surprising in general.

Martin


> 
> Given:
> 
>     typedef int arr10[10];
>     typedef int arr_unknown[];
>     typedef int *arr;
>     typedef struct named { int a; int b; } named_t;
>     typedef struct { int a; int b; } nameless_t;
>     typedef void (*func_arr10)(int[10]);
>     typedef void (*func_arr_unknown)(int[]);
>     typedef void (*func_ptr)(int*);
>     typedef void (*func_named(named_t*);
>     typedef void (*func_nameless(nameless_t*);
> 
> C++ typeinfo(...).name() shows:
> 
>   int[10]:		A10_i
>   int[]:		A_i
>   int *:		Pi
>   named_t:		5named
>   nameless_t:		10nameless_t
>   void(*)(int[10]):	PFvPiE
>   void(*)(int[]):	PFvPiE
>   void(*)(int*):	PFvPiE
>   void(*)(named_t*):	PFvP5namedE
>   void(*)(nameless_t*):	PFvP10nameless_tE
> 
> This __builtin_typeinfo_name(...) shows:
> 
>   int[10]:		A10_i
>   int[]:		A_i
>   int *:		Pi
>   __builtin_compatible_types_p(int[10], int[]): true
>   __builtin_compatible_types_p(int[], int*):	false
>   named_t:		5named
>   nameless_t:		10nameless_t
>   void(*)(int[10]):	PFvPiE
>   void(*)(int[]):	PFvPiE
>   void(*)(int*):	PFvPiE
>   void(*)(named_t*):	PFvP5namedE
>   void(*)(nameless_t*):	PFvP10nameless_tE
> 
> What would you want the "Strict ISO C" builtin to do instead?
> 
> -Kees