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] [day] [month] [year] [list]

Message-ID:
 <LV3PR12MB9265292F9654D9FF76D6B63494772@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Tue, 1 Oct 2024 01:58:56 +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: Monday, September 30, 2024 7:50 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: bp@...en8.de; dave.hansen@...ux.intel.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-09-12 14:08-0500 David Kaplan wrote:
> > @@ -446,7 +450,8 @@ static void __init mds_apply_mitigation(void)
> >      if (mds_mitigation == MDS_MITIGATION_FULL) {
> >          setup_force_cpu_cap(X86_FEATURE_CLEAR_CPU_BUF);
> >          if (!boot_cpu_has(X86_BUG_MSBDS_ONLY) &&
> > -            (mds_nosmt || cpu_mitigations_auto_nosmt()))
> > +            (mds_nosmt || cpu_mitigations_auto_nosmt() ||
> > +             cpu_mitigate_attack_vector(CPU_MITIGATE_CROSS_THREAD)))
> >              cpu_smt_disable(false);
> >      }
> >  }
>
> 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.
>
> Derek

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.

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.

--David Kaplan