[MODERATED] Re: [PATCH v2 5/8] MDSv2 7

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Dec 10, 2018 at 09:53:37AM -0800, speck for Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 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 <ak@linux.intel.com>
> ---
>  .../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 <asm/intel-family.h>
>  #include <asm/e820/api.h>
>  #include <asm/hypervisor.h>
> +#include <asm/hypervisor.h>
> +#include <asm/cpu_device_id.h>
>  
>  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?