Message-ID: <20180110114505.GO6176@hirez.programming.kicks-ass.net>
Date:   Wed, 10 Jan 2018 12:45:05 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
        Borislav Petkov <bp@...en8.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control
 code

On Wed, Jan 10, 2018 at 11:22:53AM +0000, David Woodhouse wrote:
> On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +0000, David Woodhouse wrote:
> > > 
> > > > 
> > > > The only question I have is if retpoline works at all on SKL (with ucode
> > > > update); BDW needs the ucode update for retpoline to work because of the
> > > > RSB fallback.
> > > As I understand it, Skylake is never getting the IBRS_ATT (all the
> > > time) feature. That is for future CPUs only.
> >
> > Ah, so then I got confused by your earlier email. So retpoline will work
> > on SKL, but it will, like BDW need the ucode update?
> 
> Er, ... I'm not sure if SKL does need the µcode update. As I understand
> it, the µcode update for BDW stops it from taking predictions for 'ret'
> from anything but the RSB, which means that RSB-stuffing is sufficient.

OK, that is what I understood as well.

> On SKL I don't think there *is* a way to stop it doing that, which is
> why we were originally saying we'd use IBRS on SKL instead.

Ah, so we need the dynamic IBRS cruft for SKL :/ I really detest the
IBRS 'feature' it would be ever so much better if we can otherwise fix
that RSB issue, but I suppose people have looked at that already.

> > Yes, continuation of the nomenclature of that earlier thread.
> 
> Except I don't think it is; I think the various IBRS= options there
> were about pointlessly fine-tuning when you frob the *existing* IBRS
> bit, not about the future IBRS_ATT bit which really is set-and-forget.

IBRS=1 was the dynamic mumbo jumbo, IBRS=2 set it once at CPU bringup
and leave it on (or rather, that was the intention, patch had holes)
IIRC.

> > Still, point remains, do we ever need that MSR fiddling dynamic IBRS
> > stuff now that we have retpolines? I would prefer to not have it if
> > there is no compelling reason for it.
> 
> We do want IBPB if we want to protect userspace processes (and VM
> guests) from each other. Although the attack mode there is relatively
> hard so *perhaps* we can resort to prayer instead?

Sure, not arguing about IBPB, I understand that bit.

> For IBRS though... yeah, good question. It *does* give additional
> protection on SKL where 'ret' might get mispredicted and the RSB-
> stuffing is not always guaranteed to be sufficient, but appealing to
> the deity of your choice might also be an acceptable mitigation there?

I'm just trying to understand the various undocumented options here. As
pjt [1] put it nicely:

"The majority of the confusion does not stem from this being complicated.
 It's that there's been great reluctance to document the details"

There just isn't clear and coherent information on this stuff around, so
everybody gets confused.


[1] https://lkml.kernel.org/r/CAPM31RKV-P40P0yUy7QjvsWT7sr2wUrBzqj_ma1trAjNiBWM3w@mail.gmail.com

Powered by blists - more mailing lists