Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

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

On Fri, 10 Oct 2025 01:14:37 +0200
Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Oct 09, 2025 at 06:13:20PM +0000, Kaplan, David wrote:
> > If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not
> > also look at alternatives that will never be enabled?
> > 
> > All the extra NOPs I think can affect performance in various ways and if
> > there was a way at compile time to know that the alternative would never be
> > enabled (because the feature is completely dependent on a cpu mitigation)
> > you could eliminate the NOPs...  
> 
> I don't see why not. That mitigations gunk should be just like any other
> CONFIG_-controllable item and not simply "leak" into the build because, oh
> well, we've done it this way from the very beginning and no one should touch
> it.
> 
> So yeah, eventually we should try this. I've been experimenting with
> untangling bugs.c today, will check how much it actually saves us when
> I finish beating the stinking pile into submission.
> 

There are systems (probably with a busybox/buildroot userspace) where,
even if everything doesn't run as root, any access that manages to add
any code will likely give you root access.
So all the mitigations are just pointless.
Similarly if you disable 'page table separation' (which 'trivially'
allows programs to read kernel memory) there is no point compiling
in anything else at all.

I'd even suspect that Linus disables them all on his kernel build system.

In both cases you may also want to compile out clac/stac because of
their performance impact on most cpu.

	David