Received: by 10.223.185.116 with SMTP id b49csp4692810wrg; Tue, 27 Feb 2018 00:34:20 -0800 (PST) X-Google-Smtp-Source: AH8x224Z/IsDoYP6mbcs4ZrMKfAQSPs5Gn2hks2PMbNCTcu9mNJLrcQDcrajFasuSakODqExJ+jJ X-Received: by 10.98.9.130 with SMTP id 2mr13411851pfj.149.1519720460845; Tue, 27 Feb 2018 00:34:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519720460; cv=none; d=google.com; s=arc-20160816; b=0UkXchEghH8Vir4lT6ziE50U4e15shXxWlXpJquCLkSslJR3LdlgpX2RWHLtAjc06P JqieDpB6VkO+uyNBm2IiKSdB32+kjdqsFYDKtjwz6GBxg1Qdi/11M3gBNQNp8CBEUNon X1u+Wlp9HPZ6ybjGdoNsI2rQZ+EwdX3Kpxh9k8uzzi3S5h2y28l8dQc0d0L/Dl6uKtwi AkZHox+KZ8Ui+NqRYAVxQ5hgN5eVjtiHcofQoqFpPkZwWbYeW+iMA4zFEtu14Nmrkodg wi9oQD/QDeX4UnC3pnqi7to7W8uhP8v49jdp/fOKcmueDvUKbg0p3d5pVdGbKKQIwE4I /jjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=I+Ewng1ekzWr0qcqVND3DEPmLlV8DIHNKIXN2nwniLw=; b=WDv1zuOPPGJcxa54XAQouuyB8sebUXukR5T74mgjWxN8OBJ345hO8ekY7h6bHgCmdy 80L7zsdOMv9v3n+hACpabaIDtT+8ppyUz88gHzAK/98zHG3VXbULCv1dL84DDG1VK6g3 UJMk/Yh7tCWQEHaOebMB4LlEK+tDx4vy8sSt9vH3Qu6Vcpgbj6dnQIygob3IeobeR9UU Jhi3t9cqnFh4U7fXWuzKjL4OJCo+uV4G1v2pAFcm+jKtrQI/AwBbCCA8zjHiWGrcP3cR hHc2KhJONj6jAypHQbmN4Uo45LiwFxntJ/KYxagm2t30Fkm2PMtXlh3TEL6yDCqxvvvn sG8Q== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si8155161plr.440.2018.02.27.00.34.06; Tue, 27 Feb 2018 00:34:20 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752096AbeB0IdV (ORCPT + 99 others); Tue, 27 Feb 2018 03:33:21 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751900AbeB0IdU (ORCPT ); Tue, 27 Feb 2018 03:33:20 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB70AEAE80; Tue, 27 Feb 2018 08:33:19 +0000 (UTC) Received: from [10.36.117.123] (ovpn-117-123.ams2.redhat.com [10.36.117.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0CEF810B0F22; Tue, 27 Feb 2018 08:33:17 +0000 (UTC) Subject: Re: [PATCH] KVM: X86: Allow userspace to define the microcode version To: Konrad Rzeszutek Wilk , Borislav Petkov , x86@kernel.org, mingo@redhat.com, tglx@linutronix.de Cc: Wanpeng Li , LKML , kvm , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= References: <20180226114409.GD4377@pd.tnic> <46cecef2-b0fb-b0c2-bbf3-983328d52763@redhat.com> <20180226121509.GE4377@pd.tnic> <24cd527d-5287-f0be-ffe8-eab341bf1d94@redhat.com> <3866d359-0ef8-6a99-6254-84890be62b93@redhat.com> <20180226122205.GG4377@pd.tnic> <20180226143912.GC22024@char.us.oracle.com> <20180226193711.GS4377@pd.tnic> <20180226205130.GZ22024@char.us.oracle.com> <20180226213019.GE9497@char.us.oracle.com> From: Paolo Bonzini Message-ID: <7bc6d899-5e24-4f3b-5919-f46359dc9756@redhat.com> Date: Tue, 27 Feb 2018 09:33:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180226213019.GE9497@char.us.oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 27 Feb 2018 08:33:19 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 27 Feb 2018 08:33:19 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pbonzini@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/02/2018 22:30, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 26, 2018 at 03:51:30PM -0500, Konrad Rzeszutek Wilk wrote: >> On Mon, Feb 26, 2018 at 08:37:11PM +0100, Borislav Petkov wrote: >>> On Mon, Feb 26, 2018 at 09:39:12AM -0500, Konrad Rzeszutek Wilk wrote: >>>> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c >>>> index d19e903214b4..87d044ce837f 100644 >>>> --- a/arch/x86/kernel/cpu/intel.c >>>> +++ b/arch/x86/kernel/cpu/intel.c >>>> @@ -144,6 +144,13 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c) >>>> { >>>> int i; >>>> >>>> + /* >>>> + * We know that the hypervisor lie to us on the microcode version so >>>> + * we may as well trust that it is running the correct version. >>>> + */ >>>> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) >>> >>> I guess >>> >>> cpu_has(c, X86_FEATURE_HYPERVISOR) >>> >>> since we're passing a ptr to the current CPU. >> >> Ah yes. Let me fix it up and repost. > > I've posted it (but I can't seem to find it on LKML). Here it is in this > thread. Also adding ingo + tglrx > > From 6abac2ccf105d57d60c094950e32139e435cbefe Mon Sep 17 00:00:00 2001 > From: Konrad Rzeszutek Wilk > Date: Mon, 26 Feb 2018 09:35:01 -0500 > Subject: [PATCH v2] x86/spectre_v2: Don't check bad microcode versions when > running under hypervisors. > > As: > 1) We know they lie about the env 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. > > CC: stable@vger.kernel.org > CC: Ingo Molnar > CC: "H. Peter Anvin" > CC: x86@kernel.org > Cc: Tom Lendacky > Cc: Andi Kleen > Cc: Borislav Petkov > Cc: Masami Hiramatsu > Cc: Arjan van de Ven > Cc: David Woodhouse > Signed-off-by: Konrad Rzeszutek Wilk > > --- > v2: Change comments to be more in line with the state of the world. > v3: Use cpu_has instead of boot_cpu_has per Borislav's review. Reviewed-by: Paolo Bonzini > --- > arch/x86/kernel/cpu/intel.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index d19e903214b4..4aa9fd379390 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -144,6 +144,13 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c) > { > 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_stepping == spectre_bad_microcodes[i].stepping) >