Message-ID: <1515583373.22302.109.camel@infradead.org>
Date:   Wed, 10 Jan 2018 11:22:53 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Peter Zijlstra <peterz@...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, 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.

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.

Do ask someone who works at Intel for confirmation of the above :)

> > I don't know why you're calling that 'IBRS=2'; are you getting confused
> > by Andrea's distro horridness?
> 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.

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

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?

When IBRS came first and retpoline was purely a performance
optimisation, it seemed to be a no-brainer: performance optimisations
don't get to say "well, it's only a *little* bit less secure but yay
it's faster!". Now with retpoline working first, it does seem
*psychologically* to be a slightly different question, but really it's
the same choice.

I don't have a real answer for precisely how hard it would be to
exploit the theoretical loopholes that retpoline opens on SKL.

One observation is that for an attacker to find a gadget is slightly
easier than it used to be, in some ways. Previously, if you found
gadgets you wanted to use, they had to *work*. They had to return to
some sane address and not just crash the system. That's not true in
speculation. They can leak the data and then crash or go off into the
weeds, but the crash will never really happen. The leak will.


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)

Powered by blists - more mailing lists