Message-ID:
 <LV3PR12MB9265967C195B64DACCD7CBF094702@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 2 Oct 2024 20:26:17 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: "Manwaring, Derek" <derekmn@...zon.com>
CC: "bp@...en8.de" <bp@...en8.de>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "x86@...nel.org" <x86@...nel.org>
Subject: RE: [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Manwaring, Derek <derekmn@...zon.com>
> Sent: Wednesday, October 2, 2024 3:12 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: bp@...en8.de; dave.hansen@...ux.intel.com; derekmn@...zon.com;
> hpa@...or.com; jpoimboe@...nel.org; linux-kernel@...r.kernel.org;
> mingo@...hat.com; pawan.kumar.gupta@...ux.intel.com; peterz@...radead.org;
> tglx@...utronix.de; x86@...nel.org
> Subject: RE: [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 2024-10-02 14:28+0000 David Kaplan wrote:
> > On 2024-10-01 22:37+0000 Derek Manwaring wrote:
> > > On 2024-10-01 01:56+0000 David Kaplan wrote:
> > > > On 2024-09-30 17:50-0700 Derek Manwaring wrote:
> > > > > Maybe I'm missing something here - if you care about user/user,
> > > > > why would you not care about cross-thread? It seems to me SMT
> > > > > should be turned off for all of the vectors.
> > > >
> > > > I broke out cross-thread separately to maintain the existing
> > > > kernel defaults, which does not disable SMT by default even if
> > > > full mitigation requires it.
> > >
> > > Ok that makes a lot of sense. My bias would be to use the vector
> > > parameters as an opportunity to make the SMT stance more obvious. So
> > > kernel's position becomes more of "I disabled SMT because you asked for
> protection with mitigate_user_user"
> > > (or any other vector). If no vector parameters are specified, SMT
> > > default would be maintained. What are your thoughts on disabling SMT
> > > if a vector parameter is explicitly supplied?
> >
> > Hmm, I'm not quite sure how to do that because mitigate_user_user
> > defaults to 'on' (again, to maintain the existing kernel defaults).
> > It seems odd to me that explicitly specifying 'mitigate_user_user=on'
> > would result in different behavior.  And I think many vulnerabilities
> > that require SMT disabled will already print out a warning if
> > mitigation is requested and SMT is enabled.  Open to ideas here...
>
> Yeah this would be awkward. Maybe the warning is enough. It just makes SMT
> such an exception.
>
> > > > In theory, cross-thread protection is only required if there is a
> > > > risk that untrusted workloads might run as siblings.  If
> > > > techniques like core scheduling are used, this might be able to be prevented I
> suppose.
> > >
> > > True, though I think it's worth making clear that doing core
> > > scheduling correctly is the user's responsibility, and the vector
> > > protection they asked for may be incomplete if there are mistakes in
> > > how they manage process cookies. Just an idea, but what if users had
> > > to ask for SMT to remain enabled if they had also asked for protection from one
> of these vectors?
> >
> > I think the fact that some mitigations will print warnings if SMT is
> > enabled might be sufficient here.  I can also add something more about
> > core scheduling in the documentation file.
>
> That works. Personally I would say make the SMT and core scheduling bits clear in
> the documentation and remove mitigate_cross_threads since it's not inherently two
> separate domains like the others are (user/kernel/guest/host).

I wanted to keep mitigate_cross_thread because a paranoid user could simply set all attack vector controls to 'on' and know they are fully mitigated against everything without having to worry about core scheduling.  Mitigating cross thread attacks doesn't always disable SMT, it depends on what CPU you're running on.  If I removed that vector, then you'd have to boot up and see if you got any warnings, and then reboot without SMT.

Part of the goal with the attack vector stuff is to be future-compatible.  So even if you're currently running on HW that doesn't require disabling SMT for mitigation, but then you move to new HW that does, you don't have to change anything as the system will remain fully mitigated.

But I do agree that cross-thread is a bit different than the other vectors, both because it's not inherently across domains but also because its relevance may be related to scheduling policy that the kernel knows nothing about (at boot time at least).

--David Kaplan

>
> It should be clear that SMT is the one case where specifying a vector will not
> necessarily give you sufficient protection (unless we can find an intuitive/low-
> surprise way to disable SMT when required to mitigate certain vulnerabilities for the
> configured vector on affected parts).
>

Powered by blists - more mailing lists