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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Oct 29, 2026 at 05:30:25AM -0700, Breno Leitao wrote:
> Hello Peter,
> 
> On Thu, Oct 29, 2026 at 11:49:38AM +0100, Peter Zijlstra wrote:
> > On Thu, Oct 29, 2026 at 03:27:23AM -0700, Breno Leitao wrote:
> > 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.
> 
> Cool, this would in fact solve my problem as well.
> 
> My goal is to make booting with mitigations=off equivalent to building
> with CONFIG_CPU_MITIGATIONS=n, so we can ship a single kernel and pick
> the mitigations at boot time. Your patches get there in a different way,
> but that doesn't matter for my use case.
> 
> 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.
> 
> Also, KBUILD_RISTFLAGS in that patch looks like a typo for
> KBUILD_RUSTFLAGS.

Haha, good one, let me fix.

> That said, can I do anything to help those patches land? I see they are
> from June, and I am wondering if anything is blocking them.
 
Mostly I just completely forgot about them :/

I've since rebased them and went back to look for robot reports on the
tree, and found one weird case where GCC-14 with an UNWIND_FP=y build
insists on not doing tail-calls which then trips up objtool noinst
validation.

I need to figure a way out of the noinstr validation puzzle. Also, lunch
and a school run. I'll try and post them soon.

Thanks!