Re: [PATCH] x86/boot/compressed: Disable jump tables for clang

[Nathan Chancellor <nathan@kernel.org>]

On Thu, Jun 25, 2026 at 09:06:17AM +0100, David Laight wrote:
> On Wed, 24 Jun 2026 15:17:39 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
> 
> > On Wed, Jun 24, 2026 at 11:55:10AM +0200, Ingo Molnar wrote:
> > > 
> > > * Ingo Molnar <mingo@kernel.org> wrote:
> > > 
> > >   
> > > > > I'm sitting on a patch to unconditionally disable jump-tables for
> > > > > x86_64:
> > > > > 
> > > > >   https://web.git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=x86/syscall  
> > > > 
> > > > In particular:
> > > > 
> > > >   https://web.git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=x86/syscall&id=76612388fe7aa41a8eb88f890d451bc17255eda0  
> > > 
> > > Side note: since arch/x86/boot/compressed/Makefile constructs
> > > its own KBUILD_CFLAGS, so a change to that Makefile will still
> > > be required to universally apply -fno-jump-tables and work
> > > around this Clang optimization in the decompression code.  
> > 
> > Right. I had intentionally kept my change scoped to clang to be less
> > controversial but in the face of Peter's series, it makes sense to do it
> > for all compilers like Ingo suggested. I have no preference for how we
> > proceed here. I don't mind sending a v2 with something like
> 
> Isn't this solving a different problem?
> Jump tables are disabled for the kernel build to avoid speculation of
> mispredicted indirect jumps.
> Here they are needed to stop the compiler output containing 'things' the
> restricted environment can't support.

Yeah but if the end result for both is just -fno-jump-tables, it is not
like the reasoning really matters all that much? Maybe it matters for
the person that comes along to blame -fno-jump-tables in the compressed
boot Makefile. In that case, my patch could be added to Peter's series
with its original justification but applied to all compilers like Ingo
suggested? Again, no real preference.

> Someone building a kernel for a local machine may want to disable all of
> the mitigations to avoid their associated costs and also enable jump
> tables to avoid the cost of all the mispredicted branches in the comparison
> tree.

Then they get to deal with the fallout of such a change :)

-- 
Cheers,
Nathan