Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2249710imm; Thu, 7 Jun 2018 07:42:05 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJHud8DwMjmFRp413HdGt/FJlUuHLxYT5+UIUmRKGW6b8jvKYZEPNjQteLbgoJPFvgkG8XI X-Received: by 2002:a17:902:820a:: with SMTP id x10-v6mr2351808pln.179.1528382525193; Thu, 07 Jun 2018 07:42:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528382525; cv=none; d=google.com; s=arc-20160816; b=bNPlXXqYOXG8DPpgjDVpgmgskxeT8MGeHeea0/ZtNGjFEFCZVVsWmYM7w6WF52KBKt gt99/VhU9jV/NHb0/KzJTu4wOy2eRTj/6bRkxM/uG64gdm1htq5vHv/v0b3Zc5FQGbfp UvBoVM0VxAQYAuEr5s6AN9wW9mGmflOT32oiJ0yNvhtP2JNgiuxHS2mPhExH+p5qiqbZ Fs6FOQ8HSoNGDbCo8WkrBwCDC0XSjqjKj2Kb0ZAj5W2WPa6Q8uQi/8xd3xyE+JVHt6j3 JQ2XGRC6FF6fKDwa93AsK70BdnqP561jfUhOlBOcit4Bdccn3T3RCuLmSbfK2o27WuPk bRnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=EnO1y14At56Yen7EGy+VeR1XbvMpVbdnKZnSEuogclo=; b=V/X4FrmEO9w6Dh3neMOIqrAgYpi6XZcOX4JuR9SSME6MWUqDwbE5U3fglJ5wc/ZEs2 v5y92V7KYMLoaiyXHrZvL4Rd/CRZ3P3zGw0/0HAQJxg4Y4DAM/L7p70keXxYHo7Z4PQh fO6pEVrPnKQofGvwYDOqkoHQ41wqwwVzM+xG+agZhYzI+Z0I1cS2Trj8C/USovviu/xv /s9KtKk0FaW06q0FoQLigkpq52SDg7JPIvPgFfYs2YejrEkf3XUduVMKA9kjtjd+ZusR +q0I8v435efFbmyN4kBSpKCHABAFcxk5q1fmi5WPkmRtqmMKvS6RY3JPXyjfHAmdnFkB u0PQ== 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 31-v6si54097247plz.364.2018.06.07.07.41.50; Thu, 07 Jun 2018 07:42:05 -0700 (PDT) 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 S934319AbeFGOjg (ORCPT + 99 others); Thu, 7 Jun 2018 10:39:36 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40506 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934304AbeFGOja (ORCPT ); Thu, 7 Jun 2018 10:39:30 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbS-0005Zs-5d; Thu, 07 Jun 2018 15:09:26 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvbC-0003CZ-4w; Thu, 07 Jun 2018 15:09:10 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Borislav Petkov" , "Paolo Bonzini" , "Konrad Rzeszutek Wilk" , "H. Peter Anvin" , "kvm" , "Thomas Gleixner" , "Wanpeng Li" , "=?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?=" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 334/410] x86/spectre_v2: Don't check microcode versions when running under hypervisors In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Rzeszutek Wilk commit 36268223c1e9981d6cfc33aff8520b3bde4b8114 upstream. As: 1) It's known that hypervisors lie about the environment anyhow (host mismatch) 2) Even if the hypervisor (Xen, KVM, VMWare, etc) provided a valid "correct" value, it all gets to be very murky when migration happens (do you provide the "new" microcode of the machine?). And in reality the cloud vendors are the ones that should make sure that the microcode that is running is correct and we should just sing lalalala and trust them. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Thomas Gleixner Reviewed-by: Paolo Bonzini Cc: Wanpeng Li Cc: kvm Cc: Krčmář Cc: Borislav Petkov CC: "H. Peter Anvin" Link: https://lkml.kernel.org/r/20180226213019.GE9497@char.us.oracle.com Signed-off-by: Ben Hutchings --- arch/x86/kernel/cpu/intel.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -68,6 +68,13 @@ static bool bad_spectre_microcode(struct { int i; + /* + * We know that the hypervisor lie to us on the microcode version so + * we may as well hope that it is running the correct version. + */ + if (cpu_has(c, X86_FEATURE_HYPERVISOR)) + return false; + for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) { if (c->x86_model == spectre_bad_microcodes[i].model && c->x86_mask == spectre_bad_microcodes[i].stepping)