From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 12 Dec 2018 21:41:59 -0000 Received: from userp2130.oracle.com ([156.151.31.86]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gXCGT-0001mX-Ko for speck@linutronix.de; Wed, 12 Dec 2018 22:41:58 +0100 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBCLYOOJ137344 for ; Wed, 12 Dec 2018 21:41:51 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2pb3n72dwg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 12 Dec 2018 21:41:51 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wBCLfnAF004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 12 Dec 2018 21:41:50 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBCLfnR3001552 for ; Wed, 12 Dec 2018 21:41:49 GMT Date: Wed, 12 Dec 2018 16:41:48 -0500 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH v2 5/8] MDSv2 7 Message-ID: <20181212214148.GS9077@char.us.oracle.com> References: <86f7d711109a095f09a0a9cfd9ca5efeba04cb23.1544464266.git.ak@linux.intel.com> MIME-Version: 1.0 In-Reply-To: <86f7d711109a095f09a0a9cfd9ca5efeba04cb23.1544464266.git.ak@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, Dec 10, 2018 at 09:53:37AM -0800, speck for Andi Kleen wrote: > From: Andi Kleen > Subject: x86/speculation/mds: Add software sequences for older > CPUs. > > On older CPUs before Broadwell clearing the CPU buffer with VERW is not > available, so we implement software sequences. These can then be > automatically patched in as needed. > > Support mitigation for Nehalem upto Broadwell. Broadwell strictly doesn't > need it because it should have the microcode update for VERW, which > is preferred. > > We add command line options to force the two different sequences, > mainly for regression testing and if someone wants to test > on pre Nehalem CPUs. > > Note to backporters: this patch requires eager FPU support. > > Note there is no Xeon Phi support so far. > > Signed-off-by: Andi Kleen > --- > .../admin-guide/kernel-parameters.txt | 10 ++ > arch/x86/include/asm/cpufeatures.h | 2 + > arch/x86/kernel/cpu/bugs.c | 59 +++++++++- > arch/x86/lib/Makefile | 1 + > arch/x86/lib/clear_cpu.S | 107 ++++++++++++++++++ > 5 files changed, 176 insertions(+), 3 deletions(-) > create mode 100644 arch/x86/lib/clear_cpu.S > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 48891572e825..16e10f92f8dd 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -2344,6 +2344,16 @@ > mds_disable [X86] > Disable workarounds for Micro-architectural Data Sampling. > > + mds=swclear [X86] > + Force using software sequence for clearing data that > + could be exploited by Micro-architectural Data Sampling. > + Normally automatically enabled when needed. s/Normally//? > + > + mds=swclearhsw [X86] > + Use Haswell/Broadwell specific sequence for clearing > + data that could be exploited by Micro-architectural Data > + Sampling. Normally automatically enabled when needed. s/Normally//? > + > mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory > Amount of memory to be used when the kernel is not able > to see the whole system memory or for test. > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index 93fab3a1e046..110759334c88 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -381,5 +381,7 @@ > #define X86_BUG_SPEC_STORE_BYPASS X86_BUG(17) /* CPU is affected by speculative store bypass attack */ > #define X86_BUG_L1TF X86_BUG(18) /* CPU is affected by L1 Terminal Fault */ > #define X86_BUG_MDS X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */ > +#define X86_BUG_MDS_CLEAR_CPU X86_BUG(20) /* CPU needs call to clear_cpu on kernel exit/idle for MDS */ > +#define X86_BUG_MDS_CLEAR_CPU_HSW X86_BUG(21) /* CPU needs Haswell version of clear cpu */ Why do we want to expose these instead of just having 'MDS' be exposed as bug? > > #endif /* _ASM_X86_CPUFEATURES_H */ > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index accab3279068..91619f7d90be 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -31,6 +31,8 @@ > #include > #include > #include > +#include > +#include > > static void __init spectre_v2_select_mitigation(void); > static void __init ssb_select_mitigation(void); > @@ -1044,11 +1046,55 @@ early_param("l1tf", l1tf_cmdline); > > #undef pr_fmt > > +static const __initconst struct x86_cpu_id cpu_mds_clear_cpu[] = { > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_NEHALEM }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_NEHALEM_G }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_NEHALEM_EP }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_NEHALEM_EX }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_WESTMERE }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_WESTMERE_EP }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_WESTMERE_EX }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_SANDYBRIDGE }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_SANDYBRIDGE_X }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_IVYBRIDGE }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_IVYBRIDGE_X }, > + {} > +}; > + > +static const __initconst struct x86_cpu_id cpu_mds_clear_cpu_hsw[] = { > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_HASWELL_CORE }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_HASWELL_X }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_HASWELL_ULT }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_HASWELL_GT3E }, > + > + /* Have MB_CLEAR with microcode update, but list just in case: */ > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_BROADWELL_CORE }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_BROADWELL_GT3E }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_BROADWELL_X }, > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_BROADWELL_XEON_D }, > + {} > +}; > + > static void mds_select_mitigation(void) > { > if (cmdline_find_option_bool(boot_command_line, "mds_disable") || > - !boot_cpu_has_bug(X86_BUG_MDS)) > + !boot_cpu_has_bug(X86_BUG_MDS)) { > setup_clear_cpu_cap(X86_FEATURE_MB_CLEAR); > + setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU_HSW); > + setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU); > + return; > + } > + > + if ((!boot_cpu_has(X86_FEATURE_MB_CLEAR) && > + x86_match_cpu(cpu_mds_clear_cpu)) || > + cmdline_find_option_bool(boot_command_line, "mds=swclear")) > + setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU); > + if ((!boot_cpu_has(X86_FEATURE_MB_CLEAR) && > + x86_match_cpu(cpu_mds_clear_cpu_hsw)) || > + cmdline_find_option_bool(boot_command_line, "mds=swclearhsw")) { > + setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU); > + setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU_HSW); > + } This all seems scream using loops and array to probe the 'swclear','swclearhsw,'off', etc?