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
