On 18.12.2023 16:40, Roger Pau Monné wrote: > On Mon, Dec 18, 2023 at 02:46:37PM +0100, Jan Beulich wrote: >> On 18.12.2023 13:11, Roger Pau Monné wrote: >>> Hello, >>> >>> I'm not as expert as Andrew in all the speculation stuff, but I will >>> try to provide some feedback. >>> >>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote: >>>> In order to be able to defer the context switch IBPB to the last >>>> possible point, add logic to the exit-to-guest paths to issue the >>>> barrier there, including the "IBPB doesn't flush the RSB/RAS" >>>> workaround. Since alternatives, for now at least, can't nest, emit JMP >>>> to skip past both constructs where both are needed. This may be more >>>> efficient anyway, as the sequence of NOPs is pretty long. >>> >>> Could you elaborate on the reason why deferring the IBPB to the exit >>> to guest path is helpful? So far it just seem to make the logic more >>> complex without nay justification (at least in the changelog). >> >> I've added "(to leave behind as little as possible)" ahead of the 1st >> comma - is that sufficient, do you think? > > Please bear with me, but I'm still uncertain. > > Even if IBRS is not enabled, and such indirect branch predictions are > at the same predictor mode, how would that be of any use to a guest? > My understanding was that the attacker is the one that has to control > the indirect branch predictor contents in order to attack the > hypervisor or other guests.
Right; see my later reply. >>>> --- >>>> I have to admit that I'm not really certain about the placement of the >>>> IBPB wrt the MSR_SPEC_CTRL writes. For now I've simply used "opposite of >>>> entry". >>> >>> Maybe it would easier to just add the MSR_PRED_CMD PRED_CMD_IBPB write >>> to the vmcs MSR load list? >>> >>> It's a one-time only AFAICT, as you would only want to do this for >>> context-switch AFAICT. >> >> That would be a back and forth of adding and removing the MSR to/from >> that list then, which I'm not convinced is helpful. With these special >> MSRs I would further be uncertain as to their effect when used via one >> of these lists. > > Hm, we do seem to already use MSR_PRED_CMD with such lists, so I would > assume they work just fine. Ah, yes, I forgot about that. Still it would be a back and forth if we wanted the MSR on the list only after a context switch, but not anymore for later VM entry. Also iirc these lists are VMX-only? Jan > Anyway, was mostly a recommendation towards clarity, because I think > the return to guest context assembly is getting rather convoluted, and > it's IMO critical for it to be easy to follow. > > Thanks, Roger.
