Messages in this thread | | | Date | Wed, 10 Jan 2018 13:41:19 +0100 | From | Andrea Arcangeli <> | Subject | Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code |
| |
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
| |