Message-ID: <202508221203.9069FDC389@keescook>
Date: Fri, 22 Aug 2025 12:23:50 -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 Fri, Aug 22, 2025 at 08:53:27AM +0200, Richard Biener wrote:
> Thanks for the write-up.  So I wonder whether a more general solution
> would be to detach "hash value" computation and assignment and leave
> that to external tooling that could do better than non-LTO can and
> the compiler working with attributed function types instead?  Say
> 
> void __attribute__((cfi_hash("voidvoidbutonlykind1"))) foo (void);

Yeah, having a way to choose different hashes was part of Joao's thesis.
Additionally, using a function attribute to salt a given function's hash
had been on the KCFI TODO list for a few years and just got implemented
in Clang last week:
https://clang.llvm.org/docs/AttributeReference.html#cfi-salt

I intend to get that implemented too, but I wanted to get the core KCFI
landed first.

> that decouples the way to arrive at the hashes from the instrumentation.
> You could then of course have compiler assisted auto-attribution
> based on function types.  So implementation-wise I'd try to separate
> both?  Oh, and somehow it reminds me of vtable verification?
> 
> That said, how's the collision rate on the kernel side?

The salting (and Joao's work) are designed specifically for dealing with
collisions; you can see the frequency graph in here:
https://security.googleblog.com/2018/10/posted-by-sami-tolvanen-staff-software.html
In the Android Linux kernel, indirect calls:
- 55% have <= 5 targets
- 7% have > 100 targets

Breaking up that long 7% tail has been the goal with either LTO analysis
to split up the groups or manual annotation (i.e. hash salt).

> What's the usual exploitation of overwriting a call function pointer?
> That is, what's a good useful function to target?  I'd guess a
> hypothetical setuid (int)?  Somehow it feels like a more academic
> thing, with other attack vectors being much more accessible?

For forward edge, it's usually calling a series of useful targets. Calling
into functions to disable SMAP/SMEP, turn off SELinux, setuid, etc. Each
of these specific cases have been hardened over the years (no non-inline
MSR manipulation, SELinux permissive knob removed, credential creation
doesn't take a default arg, etc).

What we've seen after the addition of CFI (and other hardening) in Linux
was a greater push by attackers toward the less "low-hanging fruit" of
"data only" attacks (e.g. write to the page tables, etc). Jann Horn has
a particularly sobering write-up about this via memory allocators:
https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists