Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

[Andrea Arcangeli <aarcange@redhat.com>]

On Wed, Jan 10, 2018 at 12:29:44PM +0000, David Woodhouse wrote:
> On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 12:09:34PM +0000, David Woodhouse wrote:
> > > That is not consistent with the documentation I've seen, which Intel
> > > have so far utterly failed to publish AFAICT.
> > > 
> > > "a near indirect jump/call/return may be affected by code in a less privileged
> > > prediction mode that executed AFTER IBRS mode was last written with a value of 1"
> > 
> > You must have misunderstood the context there, or the above text is
> > wrong to begin with.
> 
> That's a quote from the Intel documentation for the IBRS feature.
> Go read it, please.

Perhaps the confusing come from "less privileged prediction mode" and
you thought that meant "less privileged ring mode". It says "predction
mode" not ring 3.

Frankly I found that documentation very confusing like the inversion
of IBRS enabled really meaning IBP speculation disabled like Ingo
pointed out.

It's clear all done in a rush but we've to live with it. After all the
electric current also really flows in the opposite direction of the
arrow..

> Andrea, what part of this whole fucking mess isn't entirely batshit
> insane to start with? :)

Absolutely :).

> I think you are confused with the future IBRS_ATT option which will
> exist on new hardware. 

No, the only difference is that such option will perform best.

This is why the current default ibrs_enabled 1 ibpb_enabled 1.

That future CPUID bit will simply make the kernel boot by default with
ibrs_enabled 2 ibpb_enabled 1 and it'll perform best as it won't have
to write to SPEC_CTRL in kernel entry kernel exit vmenter/vmexit like
it commonly has to do with ibrs_enabled 1.

The only difference is that ibrs_enabled 2 will perform best, while
currently ibrs_enabled 1 performs best.

> Right now, IBRS works as I described it because that's the best they
> could do with microcode.

It works as I described but instead of arguing about specs above,
Intel should clarify that IBRS can already be set 100% of the time, be
left alone and set always, with all CPUs with SPEC_CTRL, and it's the
most secure mode available and matches the IBRS patchset with
ibrs_enabled 2.

Hope this helps clarify and of course this is so complex it's
perfectly normal to misunderstand something, but I'm confident it's
not me who misunderstood because if I did, the whole ibrs_enabled 2
that was just posted would make zero sense, that is for current CPUs
and it's the most secure option available (not less secure as you
seem to think).

Thanks,
Andrea