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.