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: <202508212211.77BED858A8@keescook>
Date: Thu, 21 Aug 2025 22:15:31 -0700
From: Kees Cook <kees@...nel.org>
To: Qing Zhao <qing.zhao@...cle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
	Richard Biener <rguenther@...e.de>,
	Andrew Pinski <andrew.pinski@....qualcomm.com>,
	"gcc-patches@....gnu.org" <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" <linux-hardening@...r.kernel.org>
Subject: Re: [RFC PATCH 3/7] kcfi: Add core Kernel Control Flow Integrity
 infrastructure

On Thu, Aug 21, 2025 at 06:09:08PM +0000, Qing Zhao wrote:
> > On Aug 21, 2025, at 10:25, Peter Zijlstra <peterz@...radead.org> wrote:
> > 
> > On Thu, Aug 21, 2025 at 01:01:37PM +0200, Richard Biener wrote:
> >> 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?
> > 
> > Any of the attacks that can result in scribbling a function pointer.
> > Typically a buffer overflow I suppose.
> > 
> > 
> > The way kCFI works is by changing the indirect call ABI. Traditionally
> > the indirect call is simply:
> > 
> >  load-pointer-into-reg
> >  call *%reg
> > 
> > kCFI changes every function to have a preamble like (with IBT and
> > retpolines and all the modern crap on):
> 
> Does “every function” mean all the function in the compilation? Not only the function whose address is taken? 

I tried to explain the specific logic on how the set of functions getting
preambles is chosen in this other reply:
https://lore.kernel.org/linux-hardening/202508211258.8DEE293@keescook/

If that didn't answer your question, let me know and I'll try again. :)

-Kees

-- 
Kees Cook