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. -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
