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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <LV3PR12MB9265C353BEB73FA98A75681794702@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 2 Oct 2024 14:28:58 +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: Tuesday, October 1, 2024 5:37 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-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