Received: by 10.223.176.5 with SMTP id f5csp713395wra; Fri, 9 Feb 2018 06:06:26 -0800 (PST) X-Google-Smtp-Source: AH8x227lfJ4rU+0/UcRmfAfihDHlVx3Y0p3dmrxDf1ZERQxWSUQbfSXvEmG0mdW7v4+zqmxUogEB X-Received: by 2002:a17:902:604a:: with SMTP id a10-v6mr1929241plt.225.1518185185947; Fri, 09 Feb 2018 06:06:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518185185; cv=none; d=google.com; s=arc-20160816; b=w+CKpKp3dYMmcfqwCmuNlrM5cn29o6/f0i3vXB0LCBj9ZrlGnuO2oA0yWTyIWaSaWO Tl6hkJPxhJMWmtT5yqXD3FYfp5oAVh0cwBm3C8F1yG/NJ6IcFz7r8gKOZ+SIHtpk4cPZ JKnfc4ykOC4gRV3XzZLojLzEGvwpEdkHqk7PA+QA4QZomxPN1rSZXOuPTI0x/qg4AdbC JF82WVDQFv6cWAN2U6rXlE67SV6iYC6r5b13GWSVwLaOjlRg+wmaOeR1DiKC8V4IqUQA tjTmP4u6hpMNsW2FFN2jtcNsvKRRvZ+TndDlcIffI2u73oJ8Y6PfLxlu79jOMo3jc6w7 Y0Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=AcvpkX9zb6R7IjWfhgcXKYB3xp6khjULdIIQ1YwjzBE=; b=nluwAl/fA3rlLd2zRnHvNDbwd3qqyiocAgtFPz4kAvV92yl1Per9zA5Rxa05zCtquW DfRvgGoDHUlaOEvUT8KAJcXQTj+X5aTqtZuh6KIj+Ge2mZzOFY/YKJZ5GZO7a0jQGNRN elvgwZhraMJft3gTk6TBBNN6vLBnT0pjogmvVuJb3UZKGOF6krY/i9BFmlsV7cBzW8vJ w5uJ8AHntJ5ZBEj87Qb7HrL9l3ho8kybRy8yWF0YBUXvPvK2YVTGvQdsdmMpxwE+mKnC eJugVQk98LBHDkNjysdEkW4uxPQHT5r0R8Gpgn8iSbvHFmvFycAd0gYgQxm79gkD/riO XA+g== 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 p15si1412218pgr.423.2018.02.09.06.06.11; Fri, 09 Feb 2018 06:06:25 -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 S1753369AbeBIOD4 (ORCPT + 99 others); Fri, 9 Feb 2018 09:03:56 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:50864 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753251AbeBINnh (ORCPT ); Fri, 9 Feb 2018 08:43:37 -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 0871F106B; Fri, 9 Feb 2018 13:43:26 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Woodhouse , Thomas Gleixner , karahmed@amazon.de, peterz@infradead.org, bp@alien8.de Subject: [PATCH 4.9 69/92] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel Date: Fri, 9 Feb 2018 14:39:38 +0100 Message-Id: <20180209133936.214516603@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180209133931.211869118@linuxfoundation.org> References: <20180209133931.211869118@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: David Woodhouse (cherry picked from commit 7fcae1118f5fd44a862aa5c3525248e35ee67c3b) Despite the fact that all the other code there seems to be doing it, just using set_cpu_cap() in early_intel_init() doesn't actually work. For CPUs with PKU support, setup_pku() calls get_cpu_cap() after c->c_init() has set those feature bits. That resets those bits back to what was queried from the hardware. Turning the bits off for bad microcode is easy to fix. That can just use setup_clear_cpu_cap() to force them off for all CPUs. I was less keen on forcing the feature bits *on* that way, just in case of inconsistencies. I appreciate that the kernel is going to get this utterly wrong if CPU features are not consistent, because it has already applied alternatives by the time secondary CPUs are brought up. But at least if setup_force_cpu_cap() isn't being used, we might have a chance of *detecting* the lack of the corresponding bit and either panicking or refusing to bring the offending CPU online. So ensure that the appropriate feature bits are set within get_cpu_cap() regardless of how many extra times it's called. Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags") Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Cc: karahmed@amazon.de Cc: peterz@infradead.org Cc: bp@alien8.de Link: https://lkml.kernel.org/r/1517322623-15261-1-git-send-email-dwmw@amazon.co.uk Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/cpu/common.c | 21 +++++++++++++++++++++ arch/x86/kernel/cpu/intel.c | 27 ++++++++------------------- 2 files changed, 29 insertions(+), 19 deletions(-) --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -718,6 +718,26 @@ static void apply_forced_caps(struct cpu } } +static void init_speculation_control(struct cpuinfo_x86 *c) +{ + /* + * The Intel SPEC_CTRL CPUID bit implies IBRS and IBPB support, + * and they also have a different bit for STIBP support. Also, + * a hypervisor might have set the individual AMD bits even on + * Intel CPUs, for finer-grained selection of what's available. + * + * We use the AMD bits in 0x8000_0008 EBX as the generic hardware + * features, which are visible in /proc/cpuinfo and used by the + * kernel. So set those accordingly from the Intel bits. + */ + if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) { + set_cpu_cap(c, X86_FEATURE_IBRS); + set_cpu_cap(c, X86_FEATURE_IBPB); + } + if (cpu_has(c, X86_FEATURE_INTEL_STIBP)) + set_cpu_cap(c, X86_FEATURE_STIBP); +} + void get_cpu_cap(struct cpuinfo_x86 *c) { u32 eax, ebx, ecx, edx; @@ -812,6 +832,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c) c->x86_capability[CPUID_8000_000A_EDX] = cpuid_edx(0x8000000a); init_scattered_cpuid_features(c); + init_speculation_control(c); } static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c) --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -140,28 +140,17 @@ static void early_init_intel(struct cpui rdmsr(MSR_IA32_UCODE_REV, lower_word, c->microcode); } - /* - * The Intel SPEC_CTRL CPUID bit implies IBRS and IBPB support, - * and they also have a different bit for STIBP support. Also, - * a hypervisor might have set the individual AMD bits even on - * Intel CPUs, for finer-grained selection of what's available. - */ - if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) { - set_cpu_cap(c, X86_FEATURE_IBRS); - set_cpu_cap(c, X86_FEATURE_IBPB); - } - if (cpu_has(c, X86_FEATURE_INTEL_STIBP)) - set_cpu_cap(c, X86_FEATURE_STIBP); - /* Now if any of them are set, check the blacklist and clear the lot */ - if ((cpu_has(c, X86_FEATURE_IBRS) || cpu_has(c, X86_FEATURE_IBPB) || + if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) || + cpu_has(c, X86_FEATURE_INTEL_STIBP) || + cpu_has(c, X86_FEATURE_IBRS) || cpu_has(c, X86_FEATURE_IBPB) || cpu_has(c, X86_FEATURE_STIBP)) && bad_spectre_microcode(c)) { pr_warn("Intel Spectre v2 broken microcode detected; disabling Speculation Control\n"); - clear_cpu_cap(c, X86_FEATURE_IBRS); - clear_cpu_cap(c, X86_FEATURE_IBPB); - clear_cpu_cap(c, X86_FEATURE_STIBP); - clear_cpu_cap(c, X86_FEATURE_SPEC_CTRL); - clear_cpu_cap(c, X86_FEATURE_INTEL_STIBP); + setup_clear_cpu_cap(X86_FEATURE_IBRS); + setup_clear_cpu_cap(X86_FEATURE_IBPB); + setup_clear_cpu_cap(X86_FEATURE_STIBP); + setup_clear_cpu_cap(X86_FEATURE_SPEC_CTRL); + setup_clear_cpu_cap(X86_FEATURE_INTEL_STIBP); } /*