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.