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
