Re: Avoid speculative indirect calls in kernel

[Woodhouse, David]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature