Re: [PATCH v13 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure

[Kees Cook <kees@kernel.org>]

On Wed, Jul 15, 2026 at 03:34:09PM -0700, Kees Cook wrote:
> On Sat, Jun 27, 2026 at 03:57:36PM -0700, Andrea Pinski wrote:
> > On Thu, Jun 18, 2026 at 1:45 PM Kees Cook <kees@kernel.org> wrote:
> > > [...]
> > > +/* KCFI label counter, incremented by KCFI insn emission.  */
> > > +static int kcfi_labelno = 0;
> > 
> > I am not 100% sure if this needs a GTY marker or not. I suspect no
> > because we should not have emitted assembly code yet.
> 
> If this moves with kcfi_next_labelno into final, I think it's okay
> without GTY?

This is an int, so GC shouldn't be an issue.

> > > +      type_id = (uint32_t) TREE_INT_CST_LOW (value);
> > > +    }
> > > +  else
> > > +    {
> > > +      type_id = compute_kcfi_type_id (fn_type);
> > > +
> > > +      tree type_id_tree = build_int_cst (unsigned_type_node, type_id);
> > > +      tree attr = build_tree_list (kcfi_type_id_attr, type_id_tree);
> > > +
> > > +      TYPE_ATTRIBUTES (fn_type) = chainon (TYPE_ATTRIBUTES (fn_type), attr);
> > > +    }
> > 
> > Instead of an attribute there must be a better way of doing this.
> > Maybe a hashset instead.
> 
> Perhaps? I will go examine this vs LTO, etc.

Tracking this with lifetime tied to the fndecl is going to be more pain
from what I can find. The attribute is stable and doesn't cause problems
for LTO: I've tested with 2 TUs, and this all appears to happen
post-merge? Anyway, if there is something I've missed here, I'm happy to
find a new solution, but I can't induce any problems so far.

> > > [...]
> > > +  /* Emit .type directive.  */
> > > +  ASM_OUTPUT_TYPE_DIRECTIVE (asm_file, cfi_symbol_name.c_str (), "function");
> > > +  ASM_OUTPUT_LABEL (asm_file, cfi_symbol_name.c_str ());
> > > +
> > > +  /* Emit any needed alignment padding NOPs using target's NOP template.  */
> > > +  for (int i = 0; i < kcfi_alignment_padding_nops; i++)
> > > +    output_asm_insn (kcfi_nop, NULL);
> > I think you need to calculate kcfi_nop each time you call this
> > function. Instead of caching it. For GC reasons.
> 
> Uh, do I have to? This seems wasteful: the nop is generated frequently.
> Should kcfi_nop gain GTY instead? I will take a closer look at this.

So, while I could go full GTY, I opted for xstrdup instead. I've
rearranged things here now, and indeed, LTO created some issues.
Upstream Linux doesn't have GCC LTO support (there are trees but no one
has been pushing for it), so I hadn't tested this area at all. I've
added some limited LTO testing now.

-Kees

-- 
Kees Cook