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 22:12:18 -0000 Received: from mga03.intel.com ([134.134.136.65]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gXCjo-0002Sp-0W for speck@linutronix.de; Wed, 12 Dec 2018 23:12:17 +0100 Date: Wed, 12 Dec 2018 14:12:13 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 5/8] MDSv2 7 Message-ID: <20181212221213.GK25620@tassilo.jf.intel.com> References: <86f7d711109a095f09a0a9cfd9ca5efeba04cb23.1544464266.git.ak@linux.intel.com> <20181212214148.GS9077@char.us.oracle.com> MIME-Version: 1.0 In-Reply-To: <20181212214148.GS9077@char.us.oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > > + 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//? It's not done on really old pre Nehalem CPUs, which may or may not have the problem. > > + > > 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? The patch code needs it. And I find it useful during my testing if it is exposed. > > 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? I don't believe in overdesign. -Andi