Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jan 2018 19:39:52 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Linux Kernel Mailing List <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 ML <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>, 
	"H. Peter Anvin" <hpa@...or.com>, kernel-hardening@...ts.openwall.com, 
	Thomas Gleixner <tglx@...utronix.de>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Elena Reshetova <elena.reshetova@...el.com>, 
	Alan Cox <alan@...ux.intel.com>
Subject: Re: [PATCH v2 04/19] x86: implement ifence()

On Thu, Jan 11, 2018 at 6:27 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
>
> 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.

True, I'll fix that up.

>
> 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.

Probably, but having some redundant information in the changelog eases
'git blame' archaeology expeditions in the future.

>
> 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.