[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support



>>> On 03.12.18 at 17:31, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 03/12/2018 16:24, Jan Beulich wrote:
>>>>> On 03.12.18 at 17:18, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> This is a lingering TODO item from XSA-263.  It adds support AMD's
>>> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
>>> setting into a per-vcpu setting.
>>>
>>> This can be found on:
>>>   git://xenbits.xen.org/people/andrewcoop/xen.git xen-virt-spec-ctrl-v1
>>>
>>> The start of the series is some cleanup.  It then teaches Xen to recognise 
> the
>>> available interfaces (including MSR_VIRT_SPEC_CTRL from a hypervisor), then
>>> how to safely context switch the per-core LS_CFG on Fam17h, an finally to
>>> expose support to guests.
>>>
>>> I've got some further MSR work coming because we have to fix the
>>> default-leakiness of MSRs in this range, because a guest becomes unsafe to
>>> migrate as soon as it reads any of the pipeline control MSRs.
>> I've seen you mention this elsewhere, but I'm still unclear about
>> the "why" part here.
> 
> Because the existence (or not) are model specific, the details read are
> non-architectural, not always the same on minor variations of the same
> platform, and definitely not the same across different models.

But migration then is only one (albeit perhaps the major) aspect.
CPUID overrides altering e.g. the model number would similarly
be a problem if we were to imply from reads of these MSRs that
"problematic" conclusions would be drawn by the guest.

Otoh I can't see how migration to an identical CPU model system
would become unsafe.

Nor can I see how hiding these MSRs from guests would improve
the situation in this regard: Guests may still draw unwanted
conclusions from not being able to read these MSRs, or reading
all zeros.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.