[MODERATED] Re: [PATCH 4/9] TAA 4

From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 4/9] TAA 4
Date: Thu, 24 Oct 2019 13:59:23 -0500	[thread overview]
Message-ID: <20191024185923.l2362xdrk6mlvgzq@treble> (raw)
In-Reply-To: <20191024185641.scwdwudazlqtmhpg@treble>

On Thu, Oct 24, 2019 at 01:56:41PM -0500, Josh Poimboeuf wrote:
> On Thu, Oct 24, 2019 at 07:23:57PM +0100, speck for Andrew Cooper wrote:
> > On 24/10/2019 17:43, speck for Borislav Petkov wrote:
> > > On Thu, Oct 24, 2019 at 10:32:40AM -0500, speck for Josh Poimboeuf wrote:
> > >> As I said before this would be a lot nicer if we could just add NO_TAA
> > >> to the cpu_vuln_whitelist.
> > > We're waiting for a list of CPUs from Intel here, right?
> > >
> > 
> > There is no model list required.  Vulnerability to TAA is calculable
> > directly from existing architectural sources.
> 
> Can you elaborate?  Earlier I suggested relying on NO_MDS in
> cpu_vuln_whitelist, but I believe you said that's not sufficient,
> because some of the non-MDS models don't have TSX, in which case we

meant to say: "some of the *MDS* models don't have TSX".

> shouldn't set TAA_BUG.
> 
> Which models are those?
> 
> Here's the current struct:
> 
> static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
> 	VULNWL(ANY,	4, X86_MODEL_ANY,	NO_SPECULATION),
> 	VULNWL(CENTAUR,	5, X86_MODEL_ANY,	NO_SPECULATION),
> 	VULNWL(INTEL,	5, X86_MODEL_ANY,	NO_SPECULATION),
> 	VULNWL(NSC,	5, X86_MODEL_ANY,	NO_SPECULATION),
> 
> 	/* Intel Family 6 */
> 	VULNWL_INTEL(ATOM_SALTWELL,		NO_SPECULATION),
> 	VULNWL_INTEL(ATOM_SALTWELL_TABLET,	NO_SPECULATION),
> 	VULNWL_INTEL(ATOM_SALTWELL_MID,		NO_SPECULATION),
> 	VULNWL_INTEL(ATOM_BONNELL,		NO_SPECULATION),
> 	VULNWL_INTEL(ATOM_BONNELL_MID,		NO_SPECULATION),
> 
> 	VULNWL_INTEL(ATOM_SILVERMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_SILVERMONT_D,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 
> 	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
> 
> 	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF | MSBDS_ONLY | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_AIRMONT_NP,		NO_L1TF | NO_SWAPGS),
> 
> 	VULNWL_INTEL(ATOM_GOLDMONT,		NO_TAA | NO_MDS | NO_L1TF | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_GOLDMONT_D,		NO_TAA | NO_MDS | NO_L1TF | NO_SWAPGS),
> 	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_TAA | NO_MDS | NO_L1TF | NO_SWAPGS),
> 
> 	/*
> 	 * Technically, swapgs isn't serializing on AMD (despite it previously
> 	 * being documented as such in the APM).  But according to AMD, %gs is
> 	 * updated non-speculatively, and the issuing of %gs-relative memory
> 	 * operands will be blocked until the %gs update completes, which is
> 	 * good enough for our purposes.
> 	 */
> 
> 	/* AMD Family 0xf - 0x12 */
> 	VULNWL_AMD(0x0f,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS),
> 	VULNWL_AMD(0x10,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS),
> 	VULNWL_AMD(0x11,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS),
> 	VULNWL_AMD(0x12,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS),
> 
> 	/* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */
> 	VULNWL_AMD(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS),
> 	VULNWL_HYGON(X86_FAMILY_ANY,	NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS),
> 	{}
> };
> 
> -- 
> Josh

-- 
Josh