Message-ID:
 <LV3PR12MB9265B1854AB766EBB7F098D294CD2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 27 Feb 2025 14:36:37 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>
CC: Josh Poimboeuf <jpoimboe@...nel.org>, 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: Borislav Petkov <bp@...en8.de>
> Sent: Thursday, February 27, 2025 8:09 AM
> To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Cc: Josh Poimboeuf <jpoimboe@...nel.org>; Kaplan, David
> <David.Kaplan@....com>; 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 07:50:38PM -0800, Pawan Gupta wrote:
> > Thats fair. I certainly don't want to be adding new option if we are
> > willing to live with some minor quirks with auto,nosmt.
> >
> > Like, should the order in which nosmt appears after =auto matter? IOW,
> > "=auto,no_foo,nosmt" would be equivalent to "=auto,nosmt,no_foo"? I
> > believe they should be treated the same.
>
> Yes, they should be. The order within a single mitigations=<string> shouldn't matter.
>
> > So as to treat nosmt as any other attack vector,
> > CPU_MITIGATIONS_AUTO_NOSMT should go away. I am thinking we can
> modify
> > cpu_mitigations_auto_nosmt() to check for smt attack vector:
>
> Looks like we're calling it an attack vector if I look at the cross-thread section in the
> documentation patch:
>
> https://lore.kernel.org/r/20250108202515.385902-20-david.kaplan@amd.com
>
> So I guess the cmdline format should be something like:
>
> mitigations=<global_vector_policy>;<list_of_vectors>
>
> More concretely:
>
> mitigations=(on|off|auto);((no)_<vector>)?
>
> Btw, it probably would be better to split the global policy and the vectors with ';'
> instead of ',' for an additional clarity and ease of parsing.
>
> Before this goes out of hand with bikeshedding: please think about what
> configurations we want to support and why and then design the command line
> syntax - not the other way around.
>
> I'm still not fully sold on the negative vector options. Although it sure does save
> typing.
>
> With my user hat on: If I have to do "no_user_kernel" then I probably need to go
> look what else is there. Do I want it, need it? Dunno. Maybe.
>
> If I do
>
> mitigations=;no_user_kernel
>
> then yeah, that would basically set everything else to "auto" and disable
> user_kernel.
>
> David still wants to warn if there's no global option supplied like "auto" but we can
> simply assume it is meant "auto" but warn. This is the most intuitive thing to do IMO.
>
> And when it comes to warning about nonsensical options - yap, we should do so
> when parsing.
>
> A couple more random examples as food for bikeshedding:
>
> mitigation=auto;nosmt,user_user - running untrusted user stuff, prevent user apps
> from attacking each-other, kernel protections are default
>
> mitigations=off;guest_host - running untrusted VMs, protect host from them
>
> mitigations=off;guest_host,guest_guest,cross_thread - cloud provider settings
>
> Same thing with negative options should probably be
>
> mitigations=;no_user_kernel,no_user_user
>
> Hmm, I dunno: being able to specify the same thing in two different ways is calling
> for trouble. I think we should keep it simple and do positive options first and then
> consider negative if really really needed.
>

My 2 cents is I think the negative option form is better.  That's because I'd rather err on the side of safety if the user forgets something.

For instance, in the case of 'mitigations=off;guest_host' there would be no guest->guest protection.  Did the user really intend for that?  Or did they simply forget to think about that attack vector?  In this case, their error leaves the system potentially insecure.

But if we only support the opt-out form, like 'mitigations=auto;no_guest_host' and the user forgot about guest->guest, it would leave those protections enabled.  Potentially reducing performance more than intended, but the system is more secure.

Because the existing kernel defaults things to on (the auto setting) and requires action to disable mitigations, why not keep the same logic here and only support the opt-out form?

Some specific use case examples might be:
'mitigations=auto;no_guest_guest,no_guest_host' -- Running trusted VMs
'mitigations=auto;no_user_kernel,no_user_user' -- Running untrusted VMs but trusted userspace (cloud provider setting)
'mitigations=auto;no_cross_thread' -- Using core scheduling

On the SMT piece, I think the proposal is:
'auto;<attack vectors>' -- Default SMT protections (enable cheap ones like STIBP, but never disable SMT)
'auto,nosmt;<attack vectors>' -- Full SMT protections, including disabling SMT if required
'auto;no_cross_thread,<attack vectors>' -- No SMT protections

Is that right?

--David Kaplan

Powered by blists - more mailing lists