Received: by 10.223.176.46 with SMTP id f43csp1029614wra; Wed, 24 Jan 2018 09:30:24 -0800 (PST) X-Google-Smtp-Source: AH8x227ZcxTy0X82RuPBTQ6WFjNHvjM0SkptgseLdtwPqb6TOpxaNbo3dnuZiCvFrJhC53TWChR2 X-Received: by 10.99.134.194 with SMTP id x185mr11408129pgd.252.1516815024064; Wed, 24 Jan 2018 09:30:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516815024; cv=none; d=google.com; s=arc-20160816; b=FdRb1PUIh6FabxmWJCTBj7LsI73ggMuFIMwTXMbifAUulAC938IQd+jmFFwEof++L6 +XQ5YdaIdEVi1ZpwfhzdR9fJ7Ut8ujHtVSLM3UZce8B9GpRnIffLpMUlOcxcRP+mSOZo p6zrR5awauDOY7aQM3/msRpsFmYodjaLrp1MDXyS/4P4/biEtSsnNN9Upfnh6TG5vg0G vwjqNG5sQYaS7Rnd7H5PxKIqOwX2JzE8Z/1S2NqJmtoY6RtUmDwTNocjsx9RdxEd+pb2 kxHrnPnyKvT0/UknRe13ZGqthf8J+1pJcKFhAcrtw/CCb/+JVmJP7yKAztz2fObE1wdh BtKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=jWmkdcD+v6Ra5XoI3Fx7ONTqXOkoWc1bUKgv7FHS4YU=; b=jqsa1cX714nYQhwR83xd0aapvjU5WDKsEBifwJKluasAl2910C3UCP6GIeoKNXBL5d M1Juug1SEkyut1+aBkGk3Ddras7CBTbIVZPP91UqPGkvaEjwrj9IoSN12vzhWLW46bCJ PYKfJpu/Gow5FfxT0LBEKrAAsg2A/d+GmqXyEAq0bCOMbrpzecKK5ZTuQuzjq3eTArID FFobvg9G8oveIPJw9W8GXWcwqWzGon6C1IacaDbMA+45WNWS6wydjOGaNjvus4tcMkRO jN1LxGBWTmGsm4mNDTjW3Hzxq/QxsQwU6x5nulL/eNiEJft2odYGiKf4Uf5w4yx0pAii iAfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k66si387752pgc.97.2018.01.24.09.30.09; Wed, 24 Jan 2018 09:30:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964914AbeAXR3e (ORCPT + 99 others); Wed, 24 Jan 2018 12:29:34 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:39906 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964790AbeAXR3d (ORCPT ); Wed, 24 Jan 2018 12:29:33 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id F02BD10C3; Wed, 24 Jan 2018 17:29:32 +0000 (UTC) Date: Wed, 24 Jan 2018 18:29:32 +0100 From: Greg KH To: David Woodhouse Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, dave.hansen@intel.com, gnomes@lxorguk.ukuu.org.uk Subject: Re: [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes Message-ID: <20180124172931.GG16646@kroah.com> References: <1516813025-10794-1-git-send-email-dwmw@amazon.co.uk> <1516813025-10794-7-git-send-email-dwmw@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516813025-10794-7-git-send-email-dwmw@amazon.co.uk> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 24, 2018 at 04:57:05PM +0000, David Woodhouse wrote: > We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL > if they're detected. > > AMD has a feature bit for "PRED_CMD only", which Intel didn't do. When disabling > SPEC_CTRL we can actually turn on that AMD bit to allow IBPB to still be used. > > We handle the other AMD bits here too, because hypervisors *may* have been > exposing those bits even on Intel chips, for fine-grained control of what's > available. > > Signed-off-by: David Woodhouse > --- > arch/x86/kernel/cpu/intel.c | 76 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index b720dac..f5c7f61 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -102,6 +102,64 @@ static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c) > ELF_HWCAP2 |= HWCAP2_RING3MWAIT; > } > > +/* > + * Early microcode releases for the Spectre v2 mitigation were broken. > + * Information taken from; > + * • https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf > + * • https://kb.vmware.com/s/article/52345 > + * • Microcode revisions observed in the wild > + * • releasenote from 20180108 microcode release > + */ > +struct sku_microcode { > + u8 model; > + u8 stepping; > + u32 microcode; > +}; > +static const struct sku_microcode spectre_bad_microcodes[] = { > + { INTEL_FAM6_KABYLAKE_DESKTOP, 0x0B, 0x80 }, > + /* Corrected typo in Intel doc */ > + { INTEL_FAM6_KABYLAKE_DESKTOP, 0x0A, 0x80 }, > + { INTEL_FAM6_KABYLAKE_MOBILE, 0x0A, 0x80 }, > + { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 }, > + { INTEL_FAM6_KABYLAKE_DESKTOP, 0x09, 0x80 }, > + { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003C }, > + { INTEL_FAM6_SKYLAKE_MOBILE, 0x03, 0x000000C2 }, > + { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0x000000C2 }, > + { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 }, > + { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x0000001B }, > + { INTEL_FAM6_HASWELL_ULT, 0x01, 0x21 }, > + { INTEL_FAM6_HASWELL_GT3E, 0x01, 0x18 }, > + { INTEL_FAM6_HASWELL_CORE, 0x03, 0x23 }, > + { INTEL_FAM6_IVYBRIDGE_X, 0x04, 0x42a }, > + { INTEL_FAM6_HASWELL_X, 0x02, 0x3b }, > + { INTEL_FAM6_HASWELL_X, 0x04, 0x10 }, > + { INTEL_FAM6_HASWELL_CORE, 0x03, 0x23 }, > + { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 }, > + { INTEL_FAM6_BROADWELL_XEON_D, 0x03, 0x7000011 }, > + { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x0000001B }, > + { INTEL_FAM6_BROADWELL_X, 0x01, 0x0b000025 }, > + /* Dropped repeat of KBL Desktop 906E9, 0x80 */ > + { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e }, > + /* Dropped repeat of SKX 50654, 0x200003c */ Nit, but why comment that you dropped a repeat? No one cares, do they? You already said above where this info came from. Anyway, not a big deal at all: Reviewed-by: Greg Kroah-Hartman