Re: [Xen-devel] MSR_SPEC_CTRL intercept

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel