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: <202508211207.57A1A3BCE7@keescook>
Date: Thu, 21 Aug 2025 12:57:33 -0700
From: Kees Cook <kees@...nel.org>
To: Richard Biener <rguenther@...e.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
	Andrew Pinski <andrew.pinski@....qualcomm.com>,
	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, 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?

To add some more detail to Peter's answer, the attack vector is dealing
with stored function pointers (generally on the heap, but potentially
also the stack), that can be changed by attacker-controlled writes (via
buffer overflows or use-after-free writes). The idea being that instead
of being able to call anywhere through an indirect call site that uses a
manipulated pointer, now the attacker is limited to a subset of "matching"
destinations. (KCFI depends on a system already enforcing W^X memory in
the sense that if an attacker can construct an executable region, they
could write whatever hash they want into in addition to whatever code.)

The general CFI ideas for this are discussed here, but focuses more on a
CFG analysis to construct valid call destinations, which tends to require
LTO, etc:
https://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf

Later refinement for using jump tables (constructed via CFG analysis
during LTO) was proposed here:
https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-tice.pdf
Linux used the above implementation from 2018 to 2022:
https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html
but the corner cases for target addresses not being the actual functions
(i.e. pointing into the jump table) was a continual source of problems,
and generating the jump tables required full LTO, which had its own set
of problems.

Looking at function prototypes as the source of call validity was
presented here, though still relied on LTO:
https://www.blackhat.com/docs/asia-17/materials/asia-17-Moreira-Drop-The-Rop-Fine-Grained-Control-Flow-Integrity-For-The-Linux-Kernel-wp.pdf

The KCFI approach built on the function-prototype idea, but avoided
needing LTO, and could be further updated to deal with CPU errata
(retpolines, etc):
https://lpc.events/event/16/contributions/1315/
This has been working very well now for 3 years, but has been limited to
only Linux built with Clang (e.g. Linux kernel CFI, first LLVM-CFI and now
KCFI, has been deployed on all Android phones and all Chrome OS devices
since 2018.)

I have been trying to find someone to work on KCFI in GCC since 2018,
(see my annual arm-waving at the Linux Plumbers conference Toolchain
track) and other than Dan Li who took a stab at it for aarch64 in 2023,
no one has stepped up to do it, so I thought I'd finally try tackling
it. :)

-Kees

-- 
Kees Cook