[MODERATED] Re: LVI

On Tue, Nov 19, 2019 at 11:40:08AM -0600, speck for Josh Poimboeuf wrote:
> Hi,
> 
> What kernel changes (if any) are needed for LVI?  I haven't seen any
> discussion here.
> 
> The last I heard, the official CRD was Dec 10, but was likely to move to
> March.
> 
> For the uninitiated, LVI is a reverse MDS/L1TF:
> 
> 1) Victim puts secret data in CPU buffer or L1.  Alternatively,
>    attacker puts address of secret data in CPU buffer or L1.
> 
> 2) Attacker gets victim to fault or assist on a load.  (Note that an
>    assist gives a much bigger speculation window - it can be triggered
>    if a page Accessed bit needs updating)
> 
> 3) While waiting for the fault/assist to complete, victim speculatively
>    reads CPU buffer or L1 to get data (or address) from step 1.
> 
> 4) Victim gadgets expose the data via the usual L1 side channel.
> 
> 
> To protect the kernel, we'd presumably need to look for places where
> users can trigger a faulting/assisting load.  For example,
> copy_from_user().
> 
> copy_from_user() has an LFENCE between the access_ok() check and the
> actual copy to protect against Spectre v1.  What if we move that LFENCE
> to *after* the copy?  I think that would protect against both Spectre v1
> and LVI.
> 
> Thoughts?
> 
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 61d93f062a36..457207aece71 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -119,9 +119,9 @@ extern int __get_user_bad(void);
>  
>  #define __uaccess_begin() stac()
>  #define __uaccess_end()   clac()
> -#define __uaccess_begin_nospec()	\
> +#define __uaccess_end_nospec()	\
>  ({					\
> -	stac();				\
> +	clac();				\
>  	barrier_nospec();		\
>  })

Um, don't we _really_ want stac() here?  That's the only thing that is
saving our butts in a number of places.  Why get rid of it?  Otherwise
it should be easy to cause a speculatave load by userspace for any
address they feel like.

Or am I mistaken about what you are trying to solve here?

thanks,

greg k-h