Re: [PATCH 3/3] objtool: Skip jump table jumps in the kCFI indirect call check

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Oct 12, 2026 at 11:41:03AM -0700, Kees Cook wrote:
> On Mon, Oct 12, 2026 at 11:22:50AM +0200, Peter Zijlstra wrote:
> > I am confused.. I don't see a computed goto in __bpf_prog_run(), and we
> > build with -fno-jump-tables.
> 
> It's the interpreter, ___bpf_prog_run() (three underscores) in

Durr, clearly I wasn't wearing my glasses or something.

> kernel/bpf/core.c, not the __bpf_prog_run() wrapper in filter.h:
> 
> 	static const void * const jumptable[256] __annotate_jump_table = {
> 		[0 ... 255] = &&default_label,
> 		...
> 	};
> 	...
> 	select_insn:
> 		goto *jumptable[insn->code];
> 
> So it's a manually constructed jump table, not the "normal"
> table-from-switch stuff that -fno-jump-tables suppresses (though see
> below about Clang). objtool already knows about it, with annotations
> added back in 2019 in commit e55a73251da33 ("bpf: Fix ORC unwinding in
> non-JIT BPF code").
> 
> With retpolines, GCC emits a single dispatch that every handler uses:
> 
> 	movzbl (%rbx),%esi
> 	movzbl %sil,%edx
> 	mov    jumptable(,%rdx,8),%rdx
> 	jmp    __x86_indirect_thunk_rdx
> 
> Clang never has this jump: with retpolines, LLVM's IndirectBrExpand pass
> turns the label addresses into indexes and the "goto *" into a switch,
> which Clang's -fno-jump-tables then makes a compare tree. So it's only
> constructed this way under GCC, but since now we can turn on kCFI with
> GCC, the objtool warning about indirects without kcfi protection trips.

OK, then the next question; do we *want* to allow a 'naked' indirect
branch to survive?

We can simply disable the whole interpreter when kcfi=y. Isn't that
thing recommended disabled anyway?