linux-hardening - Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity infrastructure

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] [day] [month] [year] [list]

Message-ID: <202508220139.49831A70FF@keescook>
Date: Fri, 22 Aug 2025 01:47:07 -0700
From: Kees Cook <kees@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andrew Pinski <pinskia@...il.com>,
	Andrew Pinski <andrew.pinski@....qualcomm.com>,
	Qing Zhao <qing.zhao@...cle.com>,
	GCC Patches <gcc-patches@....gnu.org>,
	Joseph Myers <josmyers@...hat.com>,
	Richard Biener <rguenther@...e.de>, 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>, linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity
 infrastructure

On Fri, Aug 22, 2025 at 10:24:20AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 22, 2025 at 09:51:15AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> > > On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > > 
> > > > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> > > >
> > > > > > +/* Compute KCFI type ID for a function declaration or function type
> > > > > > (internal) */
> > > > > > +static uint32_t
> > > > > > +compute_kcfi_type_id (tree fntype_or_fndecl)
> > > > > > +{
> > > > > > +  if (!fntype_or_fndecl)
> > > > > > +    return 0;
> > > > > > +
> > > > > > +  const char *canonical_name = mangle_function_type
> > > > (fntype_or_fndecl);
> > > > > > +  uint32_t base_type_id = kcfi_hash_string (canonical_name);
> > > > > >
> > > > >
> > > > > Now I am curious why this needs to be a mangled function name? Since the
> > > > > function in C the symbol is just its name.
> > > > > Is there documentation that says the hash needs to be based on all of the
> > > > > function arguments types?
> > > >
> > > > The whole point of kCFI is to limit the targets of indirect calls to
> > > > functions of the same signature. The actual function name is immaterial.
> > > >
> > > 
> > > 
> > > So then just hash the function argument types. It only needs to be
> > > consistent for the objects that are compiled together right?
> > 
> > Function argument and return; but yes that could be done. Ideally the
> > kCFI implementation would be compatible between compilers. Specifically
> > rust is based on llvm and therefore generates kCFI that is compatible
> > with clang. Being able to mix GCC and rust code (as the kernel does)
> > would be nice.
> 
> FWIW, Kees, for this to actually work, we need this
> CFI_ICALL_NORMALIZE_INTEGERS thing supported. Rust gets really upset
> about LP64's whole 'long' vs 'long long' trainwreck :/
> 
> That is the -fsanitize-cfi-icall-experimental-normalize-integers
> argument for clang (omg so long).

Yup! I forgot to include my "TODO" list in the RFC. It is:

 * -fsanitize-cfi-icall-experimental-normalize-integers (but this option
   needs a better name if it's going to be supported in GCC too for Rust
   compat)

 * -fsanitize-kcfi-arity
   https://clang.llvm.org/docs/ControlFlowIntegrity.html#fsanitize-kcfi-arity

 * cfi_salt function attribute
   https://clang.llvm.org/docs/AttributeReference.html#cfi-salt
   https://github.com/llvm/llvm-project/commit/aa4805a09052c1b6298718eeb6d30c33dd0d695f

-Kees

-- 
Kees Cook