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
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.
--
Kees Cook
