Re: [PATCH RFC] x86/syscall: Dispatch via sys_call_table when Spectre v2 and BHI are off

From: H. Peter Anvin

Date: Fri Oct 30 2026 - 15:04:40 EST


On October 30, 2026 11:56:12 AM PDT, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>On Thu, 29 Oct 2026 at 02:30, Breno Leitao <leitao@xxxxxxxxxx> wrote:
>>
>> With "x86_64/entry: Unconditionally use -fno-jump-table", x64_sys_call()
>> becomes a compare tree on every x86_64 build, so system call dispatch is
>> the same whether the mitigations are disabled at boot or at build time,
>> which is basically my end goal.
>
>You're basically saying "with that patch, both cases do equally badly
>whether disabled at boot or build time".
>
>That's not a good end goal. You want both cases to do equally *well*.
>
>I do wonder if we could do computed jumps. It would be lovely if we
>could basically do something like
>
> # syscall number in %rax
> leaq table(%rax,%rax,4),%rax
> jmp *%rax
>table:
> jmp syscall0
> jmp syscall1
> jmp syscall2
> ....
>
>and avoid any indirect memory lookup or indirect branches (outside of
>the one computed one). And no extra call/ret frame.
>
>It's possible that the branch prediction hardware hates those kinds of
>very dense jmp patterns, though. I don't know.
>
>We could have a single static jump that picks between this one and the
>"conditional branch tree" version, as in your patch at the beginning
>of the thread.
>
> Linus

As far as I understand, with modern hardware there is very little difference between the two in practice.

The advantage of using a branch tree is that you don't end up having any *possibility* of out-of-range speculative accesses going off into some speculative hyperspace.