Re: MSR_SPEC_CTRL intercept

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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?

-boris

>
> It is, as documented, not completely strictly true (according to the
> latest revision of the spec), but is there deliberately to simply so we
> don't give the guest implausible configurations.  There is not a
> processor with STIBP but without IBRSB, nor is there one with SSBD
> without STIBP or IBRSB, and it is unlikely that future processors would
> change this arrangement.
>
> A side effect of prohibiting the implausible configurations is that the
> logic in Xen is much more simple.
>
> ~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel