Message-ID:
 <LV3PR12MB9265F875F52317BBCDF953EC94C22@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 26 Feb 2025 21:03:58 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.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

[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.

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.

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.

--David Kaplan

Powered by blists - more mailing lists