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

[Peter Zijlstra]

On Thu, Oct 29, 2026 at 03:27:23AM -0700, Breno Leitao wrote:
> Linus' commit 1e3ad78334a6 ("x86/syscall: Don't force use of indirect
> calls for system calls") dispatches system calls with a switch
> statement, so that syscall entry has no indirect branch for BHI to
> target.
> 
> As noted by Linus in the commit above, the compiler can either
> decide to generate an indirect jump, or just a series of conditional
> branches (which is more expensive).
> 
> With CONFIG_MITIGATION_RETPOLINE, clang emits no indirect jump, and the
> switch becomes a tree of compares and conditional branches. That code is
> built in, so a kernel booted with mitigations=off still walks the tree
> on every system call.
> 
> When neither the Spectre v2 nor the BHI mitigation is enabled, nothing in
> the kernel protects indirect branches, and the switch buys nothing. Use a
> static key to call through sys_call_table[] in that case.
> 
> The compiler emits that call through a retpoline thunk, which boot-time
> patching turns into a plain indirect call when retpolines are off.
> 
> On next-20261028 built with clang and booted with mitigations=off on a
> Xeon Gold 6138 at a fixed 2.0 GHz, perf bench syscall basic (getppid)
> and getpgid. Mean and standard deviation of 30 to 45 runs over 2 to 3
> boots, and kernel instructions and cycles per call from perf stat:
> 
>                          CPU_MITIGATIONS=n  =y              =y + patch
>   getppid()  ns          131.2 +- 0.2       134.1 +- 0.1    131.7 +- 0.4
>              insns/cyc   310 / 212.1        331 / 218.1     314 / 213.1
>   getpgid()  ns          129.8 +- 0.3       132.5 +- 0.2    130.0 +- 0.5
>              insns/cyc   302 / 209.4        323 / 214.1     306 / 209.8
> 
> Kernels that enable either mitigation keep the switch, behind one extra
> jump.
> 

Bah, this reminds me I still have these patches:

 https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=x86/syscall

which make your patch impossible. The reason for not dispatching through
the syscall table is that syscall hijacking becomes a _LOT_ more
difficult.