Received: by 10.223.185.116 with SMTP id b49csp3601269wrg; Mon, 19 Feb 2018 02:54:13 -0800 (PST) X-Google-Smtp-Source: AH8x226EdtkZGIaVWw8kGbinfj0x5eWnahAa7hRFSqPNTVqyZaHJ7ziG8qDwuarFyPVXGAEK/F6+ X-Received: by 10.98.49.7 with SMTP id x7mr14364222pfx.101.1519037653317; Mon, 19 Feb 2018 02:54:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519037653; cv=none; d=google.com; s=arc-20160816; b=mBkdLJPX2kcWGkMMNW2gNWhhHZC3U1RLa7XOEkj3887d/nhl3CFzmub3gVpfMp1+ub AfZQlSQ6FsIdJV6o0MPVr5jX6y2iPIInAEkh9X8FQwXNwRxnigtkK4CX2suuAXNdvnRB sfCpTT1v/4LVqtOkt61Q0kX4L7AoM9GRXIltey+WL6XvKMKdpgrwPGkMrpGz/FYMuZmI rzQXU6hn6ZDogS3nDAkdxgaCaIt3YdrJ7uLDwLye5JH4EAJZaOmaZXa7MWb50I3ZOIhd c1zAqvMqZsjPQm7myVDNssnhNFgIYaKiiQuiGUsCQsh21lMzm/1wJlo5ahCqmty+ywAP GqFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:to:from:dkim-signature:arc-authentication-results; bh=Uyra+ub9luaXWoFJYiyZIv16RPW3z+VSJI95R2uv4QQ=; b=P/9INGfGJL3Cg03bii/juxuycR+g6ZLeR0RYsg/F9Na0itkrnEjM+f3YOhnPFKScVy OGnSJ18yjRiiZ03+ZcH56UzKY5Oj43qXY8fANHA5/oLLO7/jxEn2jhYK1FUInRskKtMg wu3Q2jRIzrmJwmcNzmMonwgvQmtb0fG96hDV+7F4M5YRLnRmqoDA0lSPKrpV9JciVkEL H4e2XIL6oSQQSbsa841K0hP4gEGn9NJdwVY4p+Xzxk3Tqn1jXI4kh+wBk44NjgmQsOwJ KsPC7SOyT5GRJ1NCz3FZ153SOs0v+wB7gbRRJgISWrZfYHVa8Gpk/aLnXwlUzF0pTjhy sE6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.co.uk header.s=amazon201209 header.b=VfqEmHc/; 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=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e9-v6si6013159plt.685.2018.02.19.02.53.58; Mon, 19 Feb 2018 02:54:13 -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; dkim=pass header.i=@amazon.co.uk header.s=amazon201209 header.b=VfqEmHc/; 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=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752638AbeBSKvT (ORCPT + 99 others); Mon, 19 Feb 2018 05:51:19 -0500 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]:56712 "EHLO smtp-fw-4101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752594AbeBSKvQ (ORCPT ); Mon, 19 Feb 2018 05:51:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1519037476; x=1550573476; h=from:to:subject:date:message-id:in-reply-to:references; bh=Uyra+ub9luaXWoFJYiyZIv16RPW3z+VSJI95R2uv4QQ=; b=VfqEmHc/lVI27lG3IE/YflPldAX4FXGy699s6S2kO+DrA2L9jMipvYDe hfR/DizQCP5JQEDSlzS8a4LYWxglS4XAcv2Aa66Tq7Mo4RMoTS7+hRi5s FjAcyCODyHQWnH3QPHJItrK9zjd7t++nh2rRJQiPKvUcpO4f/defiVXF8 U=; X-IronPort-AV: E=Sophos;i="5.46,534,1511827200"; d="scan'208";a="708596432" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2018 10:51:13 +0000 Received: from uc8d3ff76b9bc5848a9cc.ant.amazon.com (pdx2-ws-svc-lb17-vlan3.amazon.com [10.247.140.70]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w1JAp7Fi015893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Feb 2018 10:51:08 GMT Received: from uc8d3ff76b9bc5848a9cc.ant.amazon.com (localhost [127.0.0.1]) by uc8d3ff76b9bc5848a9cc.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTP id w1JAp6Tu007962; Mon, 19 Feb 2018 10:51:06 GMT Received: (from dwmw@localhost) by uc8d3ff76b9bc5848a9cc.ant.amazon.com (8.15.2/8.15.2/Submit) id w1JAp5FR007961; Mon, 19 Feb 2018 10:51:05 GMT From: David Woodhouse To: tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, kvm@vger.kernel.org, torvalds@linux-foundation.org, pbonzini@redhat.com, linux-kernel@vger.kernel.org, bp@alien8.de, peterz@infradead.org, jmattson@google.com, rkrcmar@redhat.com, arjan.van.de.ven@intel.com, dave.hansen@intel.com, mingo@kernel.org Subject: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs Date: Mon, 19 Feb 2018 10:50:55 +0000 Message-Id: <1519037457-7643-3-git-send-email-dwmw@amazon.co.uk> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1519037457-7643-1-git-send-email-dwmw@amazon.co.uk> References: <1519037457-7643-1-git-send-email-dwmw@amazon.co.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The original IBRS hack in microcode is horribly slow. For the next generation of CPUs, as a stopgap until we get a proper fix, Intel promise an "Enhanced IBRS" which will be fast. The assumption is that predictions in the BTB/RSB will be tagged with the VMX mode and ring that they were learned in, and thus the CPU will avoid consuming unsafe predictions without a performance penalty. Intel's documentation says that it is still required to set the IBRS bit in the SPEC_CTRL MSR and ensure that it remains set. Cope with this by trapping and emulating *all* access to SPEC_CTRL from KVM guests when the IBRS_ALL feature is present, so it can never be turned off. Guests who see IBRS_ALL should never do anything except turn it on at boot anyway. And if they didn't know about IBRS_ALL and they keep frobbing IBRS on every kernel entry/exit... well the vmexit for a no-op is probably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse Acked-by: Arjan van de Ven --- arch/x86/include/asm/nospec-branch.h | 9 ++++++++- arch/x86/kernel/cpu/bugs.c | 17 +++++++++++++++-- arch/x86/kvm/vmx.c | 31 +++++++++++++++++++------------ 3 files changed, 42 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index 0995c6a..34cbce3 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -141,9 +141,16 @@ enum spectre_v2_mitigation { SPECTRE_V2_RETPOLINE_MINIMAL_AMD, SPECTRE_V2_RETPOLINE_GENERIC, SPECTRE_V2_RETPOLINE_AMD, - SPECTRE_V2_IBRS, + SPECTRE_V2_IBRS_ALL, }; +extern enum spectre_v2_mitigation spectre_v2_enabled; + +static inline bool spectre_v2_ibrs_all(void) +{ + return spectre_v2_enabled == SPECTRE_V2_IBRS_ALL; +} + extern char __indirect_thunk_start[]; extern char __indirect_thunk_end[]; diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index bfca937..505c467 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -88,12 +88,14 @@ static const char *spectre_v2_strings[] = { [SPECTRE_V2_RETPOLINE_MINIMAL_AMD] = "Vulnerable: Minimal AMD ASM retpoline", [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic retpoline", [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD retpoline", + [SPECTRE_V2_IBRS_ALL] = "Mitigation: Enhanced IBRS", }; #undef pr_fmt #define pr_fmt(fmt) "Spectre V2 : " fmt -static enum spectre_v2_mitigation spectre_v2_enabled = SPECTRE_V2_NONE; +enum spectre_v2_mitigation spectre_v2_enabled = SPECTRE_V2_NONE; +EXPORT_SYMBOL_GPL(spectre_v2_enabled); #ifdef RETPOLINE static bool spectre_v2_bad_module; @@ -237,6 +239,16 @@ static void __init spectre_v2_select_mitigation(void) case SPECTRE_V2_CMD_FORCE: case SPECTRE_V2_CMD_AUTO: + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) { + u64 ia32_cap = 0; + + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap); + if (ia32_cap & ARCH_CAP_IBRS_ALL) { + mode = SPECTRE_V2_IBRS_ALL; + wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS); + goto ibrs_all; + } + } if (IS_ENABLED(CONFIG_RETPOLINE)) goto retpoline_auto; break; @@ -274,6 +286,7 @@ static void __init spectre_v2_select_mitigation(void) setup_force_cpu_cap(X86_FEATURE_RETPOLINE); } + ibrs_all: spectre_v2_enabled = mode; pr_info("%s\n", spectre_v2_strings[mode]); @@ -305,7 +318,7 @@ static void __init spectre_v2_select_mitigation(void) * Retpoline means the kernel is safe because it has no indirect * branches. But firmware isn't, so use IBRS to protect that. */ - if (boot_cpu_has(X86_FEATURE_IBRS)) { + if (mode != SPECTRE_V2_IBRS_ALL && boot_cpu_has(X86_FEATURE_IBRS)) { setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW); pr_info("Enabling Restricted Speculation for firmware calls\n"); } diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 3dec126..5dfeb11 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -3387,13 +3387,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) vmx->spec_ctrl = data; - if (!data) + if (!data && !spectre_v2_ibrs_all()) break; /* * For non-nested: * When it's written (to non-zero) for the first time, pass - * it through. + * it through unless we have IBRS_ALL and it should just be + * set for ever. * * For nested: * The handling of the MSR bitmap for L2 guests is done in @@ -9451,7 +9452,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu) * is no need to worry about the conditional branch over the wrmsr * being speculatively taken. */ - if (vmx->spec_ctrl) + if (!spectre_v2_ibrs_all() && vmx->spec_ctrl) wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); vmx->__launched = vmx->loaded_vmcs->launched; @@ -9573,11 +9574,12 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu) ); /* - * We do not use IBRS in the kernel. If this vCPU has used the - * SPEC_CTRL MSR it may have left it on; save the value and - * turn it off. This is much more efficient than blindly adding - * it to the atomic save/restore list. Especially as the former - * (Saving guest MSRs on vmexit) doesn't even exist in KVM. + * Without IBRS_ALL, we do not use IBRS in the kernel. If this + * vCPU has used the SPEC_CTRL MSR it may have left it on; + * save the value and turn it off. This is much more efficient + * than blindly adding it to the atomic save/restore list. + * Especially as the former (saving guest MSRs on vmexit) + * doesn't even exist in KVM. * * For non-nested case: * If the L01 MSR bitmap does not intercept the MSR, then we need to @@ -9586,12 +9588,17 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu) * For nested case: * If the L02 MSR bitmap does not intercept the MSR, then we need to * save it. + * + * If IBRS_ALL is present then the whole thing is a no-op fiction + * for guests and every access is trapped, so do nothing. */ - if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) - rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); + if (!spectre_v2_ibrs_all()) { + if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); - if (vmx->spec_ctrl) - wrmsrl(MSR_IA32_SPEC_CTRL, 0); + if (vmx->spec_ctrl) + wrmsrl(MSR_IA32_SPEC_CTRL, 0); + } /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); -- 2.7.4