linux-kernel - Re: Avoid speculative indirect calls in kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1515077717.12987.125.camel@amazon.co.uk>
Date:   Thu, 4 Jan 2018 14:55:17 +0000
From:   "Woodhouse, David" <dwmw@...zon.co.uk>
To:     Paolo Bonzini <pbonzini@...hat.com>, "pavel@....cz" <pavel@....cz>
CC:     "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "andi@...stfloor.org" <andi@...stfloor.org>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Avoid speculative indirect calls in kernel

On Thu, 2018-01-04 at 15:20 +0100, Paolo Bonzini wrote:
> On 04/01/2018 12:47, Woodhouse, David wrote:
> > 
> > On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote:
> > > 
> > > 
> > > > 
> > > > No, really. The full mitigation with the microcode update and IBRS
> > > > support is *slow*. Horribly slow.
> > > What is IBRS? Invalidate BRanch prediction bufferS?
> > That isn't the precise acronym, but yes.
>
> My stab at backronyming it was "indirect branch restricted speculation",
> and there's also IBPB which is "indirect branch prediction barrier".

Something like that, yeah. But remember, setting IBRS is a barrier too.
You can't just set it and forget it; you have to do it on *every* entry
into the kernel.

Later CPUs are intended to have an 'IBRS all the time' feature which is
set-and-forget, and will perform much better, I believe. If we find
we're running on a CPU with that, we'll turn off the retpoline with
alternatives.

> > 
> > The branch predictor flush that, without retpoline, we have to do on
> > every entry to the kernel. Requires new microcode, and the patches that
> > I believe Intel are *about* to post...
> Based on our experiments it was actually pretty good on Skylake, and bad
> to horrible on earlier machines.  Still, microbenchmarks were in the
> same ballpark as PTI.

That's good, because retpoline doesn't work on Skylake (since Skylake
will actually predict rets too, and then you're just completely hosed).

So on Skylake, we'll be using the basic IBRS support too, and also
alternativing out the retpoline.

> ps: BTW^2 (and this is of course not about you, David) I'm disappointed
> that for "Spectre" there was no discussion between upstream developers,
> or between Linux vendors, or in fact hardly any discussion beyond "these
> are the patches".  I understand that (unlike PTI) there was no back
> story to cover up the actual vulnerability, but... grow up, folks.
> Seriously, "these are the patches" won't fly with either upstream or
> distros.

Yeah, that could have been improved. Although I note the patch sets
that Intel were waving around did have fixes from both you and me, by
the end. It wasn't *entirely* behind closed doors.

On the retpoline side, HJ was *very* responsive to suggestions, and was
giving me a new set of GCC patches almost daily at one point.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5210 bytes)