Received: by 10.223.185.116 with SMTP id b49csp1047132wrg; Fri, 16 Feb 2018 11:26:15 -0800 (PST) X-Google-Smtp-Source: AH8x225QzO9dslJU+ZtrCRKIaToRIaNCT4S2LZ5+vpztu8ia1CWSmNkuupD/50V7S9VSB8ePx+SQ X-Received: by 2002:a17:902:96a:: with SMTP id 97-v6mr6806016plm.183.1518809175542; Fri, 16 Feb 2018 11:26:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518809175; cv=none; d=google.com; s=arc-20160816; b=dWa1IVV7OFbTtGTFAhre3COAe4JHkhrktGbQjBELccXYR2MKKlRWW79WCzN0q3dsFn c13cEGpGVUMPEkiRDLVntlqwCG/JNIlpki1vKdNlLUlMbgxEmsHVC1R3MtaSfeFsI5wg w1vHan0t+tbtM+JbWqIX515jLqVnVsm4RiV6gbY/3i1+hHskTJ2BuG9Bjgphm8/86YSI FMCa+LNMjIjZd7Dxw0Sn75OXghmc6fll6g7ve8TffXVbtE8atuv+tQVdlX25ikTrJeQe nX852LFNiXBjs6BKgS+zHOwBY2V8VbXvqojF/M6rNPk93otKH4uw8KBlaAczQCmXgdPF khIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:from:cc:to:subject :arc-authentication-results; bh=ozjfbPJ1P+Eelr66hGEPmaO9BZfdZBHI5YAP+FK/FYM=; b=KXdOFUNSMR0PKUf1XgkAZfmALRr8nvhQEpfrjSGcTJlS/8XC0cj+Q4rcVpmuPOEqBA GQwQyroZgOj0er5jrFID/sXu51ZLLuNAkhOXOoKgzJQQdPHDEhdfouD8lmkaDcsw3qcN UjAhj5m+QNbWp8VWGj+rNuPEkarm54ON5l8V2cBVc4vBL8dWF/CIKiR/r1G1TgFEN+V3 p+W2mW7OnXyV960JwrhZMpZNoS60CyiTP2MFy7Gb+xCpLecbsGGlIFt/GIVFQnTddZ8T gDNYSFZ76fGD4EQ2gE4K4F5ioUvvi1RHx7L/fdQLaajqc0uKvCeDb75GKfouqDunkz4F JG7Q== 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 91-v6si92621pld.283.2018.02.16.11.26.01; Fri, 16 Feb 2018 11:26:15 -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 S1752631AbeBPTWx (ORCPT + 99 others); Fri, 16 Feb 2018 14:22:53 -0500 Received: from mga05.intel.com ([192.55.52.43]:44848 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752545AbeBPTWY (ORCPT ); Fri, 16 Feb 2018 14:22:24 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 11:22:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,520,1511856000"; d="scan'208";a="18470001" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by fmsmga008.fm.intel.com with ESMTP; 16 Feb 2018 11:22:23 -0800 Subject: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow To: linux-kernel@vger.kernel.org Cc: Dave Hansen , torvalds@linux-foundation.org, tglx@linutronix.de, gnomes@lxorguk.ukuu.org.uk, riel@redhat.com, jpoimboe@redhat.com, thomas.lendacky@amd.com, peterz@infradead.org, jikos@kernel.org, luto@amacapital.net, keescook@google.com, gregkh@linux-foundation.org, pjt@google.com, dwmw@amazon.co.uk, x86@kernel.org, ak@linux.intel.com, tim.c.chen@linux.intel.com, arjan@linux.intel.com, dan.j.williams@intel.com, asit.k.mallick@intel.com From: Dave Hansen Date: Fri, 16 Feb 2018 11:17:55 -0800 Message-Id: <20180216191755.6F62DDEA@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Intel is considering adding a new bit to the IA32_ARCH_CAPABILITIES MSR to tell when RSB underflow might be happen. Feedback on this would be greatly appreciated before the specification is finalized. --- Background: The RSB is a microarchitectural structure that attempts to help predict the branch target of RET instructions. It is implemented as a stack that is pushed on CALL and popped on RET. Being a stack, it can become empty. On some processors, an empty condition leads to use of the other indirect branch predictors which have been targeted by Spectre variant 2 (branch target injection) exploits. Processors based on Skylake and its close derivatives have this fallback behavior and need additional mitigation to avoid RSB-empty conditions. Right now, the only place we do this "RSB stuffing" operation is at context switch. We currently have a model/family list to decide where to deploy this. Problem: However, that causes a problem in virtualization environments. They routinely expose a different model/family to guests than what the bare-metal hardware has. This, among other things, makes it easy to migrate guests between different bare-metal systems with different capabilities. However, this defeats the Skylake-generation model/family detection. Solution: To help address this issue, Intel is proposing a new bit in the IA32_ARCH_CAPABILITIES MSR. This bit, "RSB Override" (RSBO) would indicate: The CPU may predict the target of RET instructions with a predictor other than the RSB when the RSB is 'empty'. Hardware implementations may choose to set this, but it can also be set by a hypervisor that traps RDMSR and simply wants to indicate to a guest that it should deploy RSB-underflow mitigations. An OS should assume that RSB-underflow mitigations are needed both when RSBO=1 or when running on Skylake-generation processors with RSBO=0. Cc: Linus Torvalds Cc: Thomas Gleixner Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: Josh Poimboeuf Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Kees Cook Cc: Greg Kroah-Hartman Cc: Paul Turner Cc: David Woodhouse Cc: x86@kernel.org Cc: Andi Kleen Cc: Tim Chen Cc: Arjan van de Ven Cc: Dan Williams Cc: Asit Mallick --- b/arch/x86/include/asm/msr-index.h | 1 b/arch/x86/kernel/cpu/bugs.c | 47 +++++++++++++++++++++++++++++++++---- 2 files changed, 43 insertions(+), 5 deletions(-) diff -puN arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing arch/x86/kernel/cpu/bugs.c --- a/arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing 2018-02-16 10:06:56.807610157 -0800 +++ b/arch/x86/kernel/cpu/bugs.c 2018-02-16 10:43:24.281604702 -0800 @@ -218,6 +218,43 @@ static bool __init is_skylake_era(void) return false; } +/* + * This MSR has a bit to indicate whether the processor might fall back to + * the BTB. Hypervisors might lie about the model/family, breaking the + * is_skylake_era() check. They might also want the OS to deploy + * mitigations because it *might* get migrated to other hardware that has + * this behavior, even if current bare-metal hardware is not exposed. + */ +static bool cpu_has_rsb_override(void) +{ + u64 ia32_cap = 0; + + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap); + + /* RSBO == RSB Override */ + if (ia32_cap & ARCH_CAP_RSBO) + return true; + + return false; +} + +/* + * Can a RET instruction on this CPU fall back to the BTB? + */ +static bool __init cpu_ret_uses_btb(void) +{ + /* All Skylake-era processors fall back to BTB */ + if (is_skylake_era()) + return true; + + /* Does the ARCH_CAPABILITIES override the model/family we see? */ + if (cpu_has_rsb_override()) + return true; + + return false; +} + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline(); @@ -283,14 +320,14 @@ retpoline_auto: * from a shallow call stack to a deeper one. To prevent this fill * the entire RSB, even when using IBRS. * - * Skylake era CPUs have a separate issue with *underflow* of the - * RSB, when they will predict 'ret' targets from the generic BTB. - * The proper mitigation for this is IBRS. If IBRS is not supported - * or deactivated in favour of retpolines the RSB fill on context + * Some CPUs have a separate issue with *underflow* of the RSB, + * when they will predict 'ret' targets from the generic BTB. The + * proper mitigation for this is IBRS. If IBRS is not supported or + * deactivated in favour of retpolines the RSB fill on context * switch is required. */ if ((!boot_cpu_has(X86_FEATURE_PTI) && - !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) { + !boot_cpu_has(X86_FEATURE_SMEP)) || cpu_ret_uses_btb()) { setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW); pr_info("Spectre v2 mitigation: Filling RSB on context switch\n"); } diff -puN arch/x86/include/asm/msr-index.h~need-rsb-stuffing arch/x86/include/asm/msr-index.h --- a/arch/x86/include/asm/msr-index.h~need-rsb-stuffing 2018-02-16 10:10:25.738609636 -0800 +++ b/arch/x86/include/asm/msr-index.h 2018-02-16 10:12:22.880609344 -0800 @@ -68,6 +68,7 @@ #define MSR_IA32_ARCH_CAPABILITIES 0x0000010a #define ARCH_CAP_RDCL_NO (1 << 0) /* Not susceptible to Meltdown */ #define ARCH_CAP_IBRS_ALL (1 << 1) /* Enhanced IBRS support */ +#define ARCH_CAP_RSBO (1 << 2) /* Needs RSB Stuffing */ #define MSR_IA32_BBL_CR_CTL 0x00000119 #define MSR_IA32_BBL_CR_CTL3 0x0000011e _