On 23/05/2018 23:53, Boris Ostrovsky wrote: > On 05/23/2018 06:34 PM, Andrew Cooper wrote: >> On 23/05/2018 23:27, Boris Ostrovsky wrote: >>> On 05/23/2018 06:09 PM, Andrew Cooper wrote: >>>> On 23/05/2018 22:59, Boris Ostrovsky wrote: >>>>> On 05/23/2018 05:49 PM, Andrew Cooper wrote: >>>>>> On 23/05/2018 22:40, Boris Ostrovsky wrote: >>>>>>> Looking at vmx_cpuid_policy_changed(): >>>>>>> >>>>>>> >>>>>>> if ( cp->feat.ibrsb ) >>>>>>> vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); >>>>>>> else >>>>>>> vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); >>>>>>> >>>>>>> >>>>>>> Is there a reason why we are not checking cp->feat.ssbd as well? >>>>>> Yes. Read the final hunk of >>>>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef >>>>> SSBD implies IBRS --- yes, that's true. But not the other way around, no? >>>> That's not the way the dependency logic works. That hunk says "if you >>>> haven't got IBRSB, then you don't have STIBP or SSBD either". >>> I guess my actual question is --- If you have IBRSB but not SSBD (which >>> is what we have today), do we want to intercept the access and screen >>> for the guest writing the SSBD bit? >> What would that achieve in practice? TBF, I did start coding in the way >> you suggest, but came to the conclusion that it was a pointless waste. >> >> Conceptually, being able to use the SSBD bit even if you can't see it in >> CPUID is no different to "knowning" that certain instructions are >> implemented in the pipeline and using them anyway. Hiding the AES CPUID >> bit doesn't prevent the pipeline from executing the AES instructions if >> it encountered them. >> >> Furthermore, MSR_SPEC_CTRL is a frequently written MSR used in privilege >> entry/exit points - Intercepting slows your VM down massively. > > Oh, right. I was thinking about catching a write to the unadvertised > SSBD bit but I guess it doesn't buy us anything.
Indeed. Doing so would allow you to always raise a #GP fault, but the CPUID bit being clear means that the bit has reserved/undefined behaviour. It doesn't mean that a #GP fault will definitely occur if you play with it. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
