[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
