Re: [RFC PATCH 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation

[Kees Cook <kees@kernel.org>]

On Thu, Aug 21, 2025 at 11:29:35AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 21, 2025 at 12:26:37AM -0700, Kees Cook wrote:
> > Implement x86_64-specific KCFI backend:
> > 
> > - Function preamble generation with type IDs positioned at -(4+prefix_nops)
> >   offset from function entry point.
> > 
> > - 16-byte alignment of KCFI preambles using calculated prefix NOPs:
> >   aligned(prefix_nops + 5, 16) to maintain cache lines.
> > 
> > - Type-id hash avoids generating ENDBR instruction in type IDs
> >   (0xfa1e0ff3/0xfb1e0ff3 are incremented by 1 to prevent execution).
> > 
> > - On-demand scratch register allocation strategy (r11 as needed).
> >   The clobbers are available both early and late.
> > 
> > - Atomic bundled KCFI check + call/branch sequences using UNSPECV_KCFI
> >   to prevent optimizer separation and maintain security properties.
> > 
> > - Uses the .kcfi_traps section for debugger/runtime metadata.
> > 
> > Assembly Code Pattern layout required by Linux kernel:
> >   movl $inverse_type_id, %r10d  ; Load expected type (0 - hash)
> >   addl offset(%target), %r10d   ; Add stored type ID from preamble
> >   je .Lpass                     ; Branch if types match (sum == 0)
> >   .Ltrap: ud2                   ; Undefined instruction trap on mismatch
> >   .Lpass: call/jmp *%target     ; Execute validated indirect transfer
> > 
> > The initialization of the kcfi callbacks in ix86_option_override()
> > seems like a hack. I couldn't find a better place to do this.
> > 
> > Build and run tested on x86_64 Linux kernel with various CPU errata
> > handling alternatives and FineIBT.
> 
> I'm a little confused, does this force r11 to be the indirect call
> register like clang does? The code seems to suggest it is possible it
> uses another register.
> 
> The current kernel FineIBT code hard assumes r11 for now.

Oh, it looked like it wasn't always r11. Does clang force the call
register to be r11? I only do that here if the call expression isn't a
register (similar to -mindirect-branch-register). Looking at the retpoline
implementation, I see __x86_indirect_thunk_* being generated for all the
general registers. Hm, but in looking now I see all the hard-coded r11 use
in the fineibt alternatives. I wonder if my boot testing is somehow not
triggering the FineIBT alternatives patching? I will investigate more...

-- 
Kees Cook