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

[David Laight <david.laight.linux@gmail.com>]

On Fri, 30 Oct 2026 08:56:12 -1000
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 29 Oct 2026 at 02:30, Breno Leitao <leitao@debian.org> 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.

Could it be a table of 32bit offsets (from some point) so that it is
a data cache access (or miss) rather than an instruction pipeline stall.
You might need to use a retpoline to avoid needing endbra.
(or is there another way of avoiding the need for endbra?)
You probably need to patch at least some of the code to nops when it isn't
being used.

> 
> It's possible that the branch prediction hardware hates those kinds of
> very dense jmp patterns, though. I don't know.

Some cpu have definitely not liked having a lot of branches in one cache line.

And performance will be absolutely horrid unless you are doing a benchmark
that keeps doing the same system call.

The cost of each branch miss is likely to be at least 20 clocks.
For a random system call half of the branches will be misses.
Plus all the cache line reads and other delays.
Definitely non-trivial.

David
 
> 
> 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
>