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

Message-ID: <q93o5262-po30-8n51-o17s-qrn0q96o51qp@fhfr.qr>
Date: Thu, 21 Aug 2025 13:01:37 +0200 (CEST)
From: Richard Biener <rguenther@...e.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: Andrew Pinski <andrew.pinski@....qualcomm.com>, 
    Kees Cook <kees@...nel.org>, Qing Zhao <qing.zhao@...cle.com>, 
    gcc-patches@....gnu.org, Joseph Myers <josmyers@...hat.com>, 
    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 Thu, 21 Aug 2025, Peter Zijlstra 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.

What's the attack vector and how does kCFI achieve mitigating it?

Richard.