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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a1c086540742c8adb0ce35246d68e01629d7e93c.camel@gmail.com>
Date: Thu, 18 Sep 2025 20:40:52 +0200
From: Martin Uecker <ma.uecker@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Qing Zhao <qing.zhao@...cle.com>, Andrew Pinski <pinskia@...il.com>, 
 Jakub Jelinek <jakub@...hat.com>, Richard Biener <rguenther@...e.de>,
 Joseph Myers <josmyers@...hat.com>,  Peter Zijlstra <peterz@...radead.org>,
 Jan Hubicka <hubicka@....cz>, Richard Earnshaw <richard.earnshaw@....com>, 
 Richard Sandiford <richard.sandiford@....com>, Marcus Shawcroft
 <marcus.shawcroft@....com>, Kyrylo Tkachov	 <kyrylo.tkachov@....com>, Kito
 Cheng <kito.cheng@...il.com>, Palmer Dabbelt	 <palmer@...belt.com>, Andrew
 Waterman <andrew@...ive.com>, Jim Wilson	 <jim.wilson.gcc@...il.com>, Dan
 Li <ashimida.1990@...il.com>, Sami Tolvanen	 <samitolvanen@...gle.com>,
 Ramon de C Valle <rcvalle@...gle.com>, Joao Moreira	
 <joao@...rdrivepizza.com>, Nathan Chancellor <nathan@...nel.org>, Bill
 Wendling	 <morbo@...gle.com>, "gcc-patches@....gnu.org"
 <gcc-patches@....gnu.org>,  "linux-hardening@...r.kernel.org"	
 <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH v3 1/7] typeinfo: Introduce KCFI typeinfo mangling API

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@...nel.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