From: Sean Christopherson <seanjc@google.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Ellerman <mpe@ellerman.id.au>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH 1/2] cpu: Re-enable CPU mitigations by default for !X86 architectures
Date: Fri, 19 Apr 2024 16:57:03 -0700 [thread overview]
Message-ID: <ZiMEz0ekQ6Tl7qh-@google.com> (raw)
In-Reply-To: <20240419173429.dj6nzgg3t23f52ol@treble>
On Fri, Apr 19, 2024, Josh Poimboeuf wrote:
> On Fri, Apr 19, 2024 at 09:46:58AM -0700, Sean Christopherson wrote:
> > > It seems confusing to have two config options which have very similar
> > > names and similar purposes (with subtle differences depending on the
> > > arch).
> > >
> > > How about we instead just get rid of the x86-specific
> > > SPECULATION_MITIGATIONS and replace it with a menu which depends on
> > > CPU_MITIGATIONS:
> >
> > Huh, didn't realize that was possible.
> >
> > I agree that having two things for the same thing is confusing, though Boris'
> > idea to do s/SPECULATION_MITIGATIONS/X86_CPU_MITIGATIONS would help a fair bit
> > on that front.
> >
> > My only hesitation is that x86's menu and the common config knob end up in
> > completely different locations.
>
> I'm thinking this is a minor issue because CPU_MITIGATIONS is enabled by
> default, so it should almost always be enabled unless the user disables
> it, in which case they wouldn't be looking for the x86-specific
> mitigations anyway.
Yeah, this isn't a sticking point by any means.
Oh, and another hiccup I almost forgot about (I just recalled Geert's report).
Letting CPU_MITIGATIONS be disabled for every arch at compile time will obsolete
a small amount of kernel code, e.g. arm64 explicitly says "disabled by command
line option" in a few places.
Those are easy enough to fixup though, but it's not clear that other architectures
*want* to allow mitigations to be completely compiled out. x86 appears to be
relatively unique in that it has a bajillion different things being mitigated.
Rather than making CPU_MITIGATIONS configured for all architectures, what if
use another Kconfig to tell common code that arch code has already defined
CPU_MITIGATIONS? The big downside is that if another arch does end up letting
the user disable CPU_MITIGATIONS, then we'll probably end up duplicating the
help text. But again, it's not clear that any other arch wants to allow that,
i.e. we can cross that bridge if we come to it.
config ARCH_CONFIGURES_CPU_MITIGATIONS
bool
if !ARCH_CONFIGURES_CPU_MITIGATIONS
config CPU_MITIGATIONS
def_bool y
endif
> Regardless it seems very common for a menu "depends on" to be in a
> different file. We could put CPU_MITIGATIONS in arch/Kconfig which is a
> fairly logical place for the dependency.
Yeah, arch/Kconfig is probably better than init/Kconfig.
Given that it's late on Friday, I'll somewhat speculatively (ba-dump ching!) post
a v2, and Cc Linus to explain the mess so that he can apply it directly if he
thinks it's urgent enough to squeeze into -rc5, and if if my idea isn't completely
off the rails.
next prev parent reply other threads:[~2024-04-19 23:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 0:15 [PATCH 0/2] cpu: Fix default mitigation behavior Sean Christopherson
2024-04-17 0:15 ` [PATCH 1/2] cpu: Re-enable CPU mitigations by default for !X86 architectures Sean Christopherson
2024-04-18 0:54 ` Michael Ellerman
2024-04-19 14:27 ` Geert Uytterhoeven
2024-04-19 14:37 ` Will Deacon
2024-04-19 16:05 ` Josh Poimboeuf
2024-04-19 16:46 ` Sean Christopherson
2024-04-19 17:34 ` Josh Poimboeuf
2024-04-19 23:57 ` Sean Christopherson [this message]
2024-04-19 23:27 ` Michael Ellerman
2024-04-17 0:15 ` [PATCH 2/2] cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n Sean Christopherson
2024-04-19 15:00 ` Borislav Petkov
2024-04-19 16:01 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiMEz0ekQ6Tl7qh-@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jpoimboe@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).