[MODERATED] Re: [PATCH 5/5] SSB extra 4

[Jiri Kosina <jkosina@suse.com>]

On Thu, 3 May 2018, speck for Dave Hansen wrote:

> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 0e17379..947ae8a 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -11,6 +11,7 @@
>  #include <linux/init.h>
>  #include <linux/utsname.h>
>  #include <linux/cpu.h>
> +#include <linux/filter.h>
>  #include <linux/module.h>
>  #include <linux/nospec.h>
>  #include <linux/prctl.h>
> @@ -148,10 +149,23 @@ EXPORT_SYMBOL_GPL(x86_get_default_spec_ctrl);
>  
>  static inline u64 intel_rds_mask(void)
>  {
> +	u64 mask;
> +
>  	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
>  		return 0;
>  
> -	return rds_tif_to_spec_ctrl(current_thread_info()->flags);
> +	mask = rds_tif_to_spec_ctrl(current_thread_info()->flags);
> +
> +	/*
> +	 * BPF programs can be exploited to attack the kernel.
> +	 * Leave the RDS bit on when we recently ran one.  This
> +	 * bit gets cleared after a BFP program has not run on
> +	 * the CPU for a while.
> +	 */
> +	if (get_cpu_var(bpf_prog_ran))
> +		mask |= SPEC_CTRL_RDS;
> +
> +	return mask;

I know that different aproach is being taken for BPF mitigation, but in 
case anyone is basing his first wave of updates on this ...

This doesn't look right. intel_rds_mask() is being called whenever 
X86_FEATURE_IBRS is set && vendor is X86_VENDOR_INTEL.

There is no check whatsoever whether X86_FEATURE_RDS is set, and therefore 
on ucode / kernel combination that has X86_FEATURE_IBRS but doesn't have 
X86_FEATURE_RDS, the RDS bits gets set in the MSR value anyway.

-- 
Jiri Kosina
SUSE Labs