Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jan 2018 20:27:45 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-kernel@...r.kernel.org,  Mark Rutland <mark.rutland@....com>,  Tom Lendacky <thomas.lendacky@....com>,  linux-arch@...r.kernel.org,  Greg KH <gregkh@...uxfoundation.org>,  Peter Zijlstra <peterz@...radead.org>,  Alan Cox <alan.cox@...el.com>,  x86@...nel.org,  Ingo Molnar <mingo@...hat.com>,  "H. Peter Anvin" <hpa@...or.com>,  kernel-hardening@...ts.openwall.com,  tglx@...utronix.de,  torvalds@...ux-foundation.org,  akpm@...ux-foundation.org,  Elena Reshetova <elena.reshetova@...el.com>,  alan@...ux.intel.com
Subject: Re: [PATCH v2 04/19] x86: implement ifence()

Dan Williams <dan.j.williams@...el.com> writes:

> The new barrier, 'ifence', ensures that no instructions past the
> boundary are speculatively executed.

This needs a much better description.

If that description was valid we could add ifence in the syscall
entry path and not have any speculative execution to worry about in the
kernel.

Perhaps:
'ifence', ensures that no speculative execution that reaches the 'ifence'
boundary continues past the 'ifence' boundary.

> Previously the kernel only needed this fence in 'rdtsc_ordered', but it
> can also be used as a mitigation against Spectre variant1 attacks that
> speculative access memory past an array bounds check.
>
> 'ifence', via 'ifence_array_ptr', is an opt-in fallback to the default
> mitigation provided by '__array_ptr'. It is also proposed for blocking
> speculation in the 'get_user' path to bypass 'access_ok' checks. For
> now, just provide the common definition for later patches to build
> upon.

This part of the description is probably unnecessary.

Eric

>
> Suggested-by: Peter Zijlstra <peterz@...radead.org>
> Suggested-by: Alan Cox <alan.cox@...el.com>
> Cc: Tom Lendacky <thomas.lendacky@....com>
> Cc: Mark Rutland <mark.rutland@....com>
> Cc: Greg KH <gregkh@...uxfoundation.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: x86@...nel.org
> Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> ---
>  arch/x86/include/asm/barrier.h |    4 ++++
>  arch/x86/include/asm/msr.h     |    3 +--
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index 7fb336210e1b..b04f572d6d97 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -24,6 +24,10 @@
>  #define wmb()	asm volatile("sfence" ::: "memory")
>  #endif
>  
> +/* prevent speculative execution past this barrier */
> +#define ifence() alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC, \
> +				   "lfence", X86_FEATURE_LFENCE_RDTSC)
> +
>  #ifdef CONFIG_X86_PPRO_FENCE
>  #define dma_rmb()	rmb()
>  #else
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 07962f5f6fba..e426d2a33ff3 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -214,8 +214,7 @@ static __always_inline unsigned long long rdtsc_ordered(void)
>  	 * that some other imaginary CPU is updating continuously with a
>  	 * time stamp.
>  	 */
> -	alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC,
> -			  "lfence", X86_FEATURE_LFENCE_RDTSC);
> +	ifence();
>  	return rdtsc();
>  }
>  

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.