Message-ID: <20250226221324.hq2nevnnnrpgo75n@desk>
Date: Wed, 26 Feb 2025 14:13:24 -0800
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors

On Wed, Feb 26, 2025 at 09:03:58PM +0000, Kaplan, David wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> > -----Original Message-----
> > From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> > Sent: Wednesday, February 26, 2025 2:15 PM
> > To: Kaplan, David <David.Kaplan@....com>
> > Cc: Josh Poimboeuf <jpoimboe@...nel.org>; Borislav Petkov <bp@...en8.de>;
> > Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>; Ingo
> > Molnar <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> > x86@...nel.org; H . Peter Anvin <hpa@...or.com>; linux-kernel@...r.kernel.org
> > Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Feb 26, 2025 at 06:57:05PM +0000, Kaplan, David wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > -----Original Message-----
> > > > From: Josh Poimboeuf <jpoimboe@...nel.org>
> > > > Sent: Thursday, February 20, 2025 4:05 PM
> > > > To: Borislav Petkov <bp@...en8.de>
> > > > Cc: Kaplan, David <David.Kaplan@....com>; Thomas Gleixner
> > > > <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>; Pawan
> > > > Gupta <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar
> > > > <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> > > > x86@...nel.org; H . Peter Anvin <hpa@...or.com>;
> > > > linux-kernel@...r.kernel.org
> > > > Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors
> > > >
> > > > Caution: This message originated from an External Source. Use proper
> > > > caution when opening attachments, clicking links, or responding.
> > > >
> > > >
> > > > On Tue, Feb 18, 2025 at 09:52:03AM +0100, Borislav Petkov wrote:
> > > > > On Mon, Feb 17, 2025 at 11:05:01PM -0800, Josh Poimboeuf wrote:
> > > > > > IMO, make them generic from the start, then there's less churn
> > > > > > and it's easy to port the other arches.
> > > > > >
> > > > > > If we went with putting everything in "mitigations=", making
> > > > > > them generic would be the obvious way to go anyway.
> > > > >
> > > > > Just to make sure we're all on the same page: we obviously cannot
> > > > > enable and test and support a mitigaion on another arch like, say, arm64, or
> > so.
> > > > >
> > > > > This needs to come from the respective arch maintainers themselves
> > > > > and they'll have to say, yes, pls, enable it and we'll support it.
> > > > > We should not go "oh, this would be a good idea to do on all arches"
> > > > > without hearing from them first, even if it is a good idea on its face.
> > > > >
> > > > > That's why those are x86-only as they should be initially.
> > > >
> > > > I wasn't suggesting that this patch set should *enable* it on all
> > > > arches.  Of course that would need to be reviewed by the respective arch
> > maintainers.
> > > >
> > > > But looking ahead, this *will* be needed for the other arches, for
> > > > the same reason we have a generic mitigations=off.  It's a user problem, not an
> > arch-specific one.
> > > > Users need a simple interface that works everywhere.  That's why I
> > > > suggested integrating it into "mitigations=".
> > > >
> > >
> > > Talked with Boris on the side, he is ok with supporting this in mitigations=, with a
> > warning message if you try to use these controls on yet-unsupported architectures.
> > >
> > > Going back to the command line definition, I think that to help make the selection
> > clearer we could consider the following format:
> > >
> > > mitigations=[on/off],[attack vectors]
> > >
> > > For example:
> > >
> > > "mitigations=on,no_user_kernel" to enable all attack vectors except
> > > user->kernel "mitigations=off,guest_host" to disable all vectors
> > > except guest->host
> >
> > This is a bit ambiguous, mitigations=off,guest_host could be interpreted as disabling
> > guest->host and enabling all others. Using attack vectors with both =on and =off
> > seems unnecessary.
> >
> > Also, we currently don't have mitigations=on option, it's equivalent is =auto.
> >
> > static int __init mitigations_parse_cmdline(char *arg) {
> >         if (!strcmp(arg, "off"))
> >                 cpu_mitigations = CPU_MITIGATIONS_OFF;
> >         else if (!strcmp(arg, "auto"))
> >                 cpu_mitigations = CPU_MITIGATIONS_AUTO;
> >         else if (!strcmp(arg, "auto,nosmt"))
> >                 cpu_mitigations = CPU_MITIGATIONS_AUTO_NOSMT;
> >         else
> >                 pr_crit("Unsupported mitigations=%s, system may still be vulnerable\n",
> >                         arg);
> >
> >         return 0;
> > }
> >
> > Extending =auto to take attack vectors is going to be tricky, because it already
> > takes ",nosmt" which would conflict with ",no_cross_thread".
> >
> > How about we keep =off, and =auto as is, and add:
> >
> >   mitigations=selective,no_user_kernel,no_cross_thread,...
> >
> > Requiring the user to explicitly select attack vectors to disable (rather than to
> > enable). This would be more verbose, but it would be clear that the user is explicitly
> > selecting attack vectors to disable. Also, if a new attack vector gets added in future,
> > it would be mitigated by default, without requiring the world to change their cmdline.
> 
> I kind of like that.
> 
> Note that for the SMT stuff, my new plan had been to use a separate
> option 'mitigate_smt' which will be on/off/auto.

I would avoid that, because we can't drop support for
"mitigations=auto,nosmt" and we also have a separate cmdline parameter
"nosmt":

	nosmt		[KNL,MIPS,PPC,S390,EARLY] Disable symmetric multithreading (SMT).
			Equivalent to smt=1.

			[KNL,X86,PPC] Disable symmetric multithreading (SMT).
			nosmt=force: Force disable SMT, cannot be undone
				     via the sysfs control file.

> But we could also combine that with mitigations=selective perhaps with
> tokens like 'mitigate_smt' (enable all relevant SMT mitigations including
> disabling SMT if needed) or 'no_mitigate_smt' (do not enable any SMT
> mitigation).  If no token is specified, then we'd default to the behavior
> today where SMT won't be disabled but other mitigations get applied.
> Then everything is in one option.

Agree.

> If we like that, then a related question then, do we agree that
> 'mitigations=off' should be equivalent to
> 'mitigations=selective,no_user_kernel,no_user_user,no_guest_host,no_guest_guest,no_mitigate_smt'?
> 
> If so, and we're ok with individual bug cmdlines overriding this, then I
> think we can get rid of cpu_mitigations_off() and just rely on the attack
> vectors as Josh was suggesting.

Does that mean to stop supporting "mitigations=off"?

Powered by blists - more mailing lists