lkml.org 
[lkml]   [2018]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Avoid speculative indirect calls in kernel
    Date
    From
    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.[unhandled content-type:application/x-pkcs7-signature]
    \
     
     \ /
      Last update: 2018-01-04 15:56    [W:4.277 / U:0.472 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site