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: <202509181009.CBFE970D@keescook>
Date: Thu, 18 Sep 2025 11:09:31 -0700
From: Kees Cook <kees@...nel.org>
To: Martin Uecker <uecker@...raz.at>
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

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

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

-- 
Kees Cook