RE: [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Manwaring, Derek <derekmn@xxxxxxxxxx>
> Sent: Tuesday, October 1, 2024 5:37 PM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: bp@xxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; derekmn@xxxxxxxxxx;
> hpa@xxxxxxxxx; jpoimboe@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> mingo@xxxxxxxxxx; pawan.kumar.gupta@xxxxxxxxxxxxxxx; peterz@xxxxxxxxxxxxx;
> tglx@xxxxxxxxxxxxx; x86@xxxxxxxxxx
> 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-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...

>
> > 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?
>
> Derek

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.

--David Kaplan