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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.12.18 at 14:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/12/2018 12:45, Jan Beulich wrote:
>>>>> On 04.12.18 at 12:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 04/12/2018 09:45, Jan Beulich wrote:
>>>> 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.
>>> I can't help but feel that the observations you've made answer the
>>> question very succinctly.
>>>
>>> Of course we can't prevent the guest drawing conclusions from the
>>> absense/presence of the information.  What we can (and must) ensure is
>>> that the information that is available (i.e. a #GP fault) does not have
>>> any details which are specific to the processor that the VM happened to
>>> boot on.
>> But that's the issue: Even #GP on such an MSR access convey
>> information. An OS may legitimately assume
>> - no #GP based on the family/model/stepping values
>> - old hardware if #GP is observed upon reading (which in turn
>>   may mean it works in a sub-optimal way)
>> - brokenness if no #GP but an all zero value, but if the BKGD
>>   documents certain bits to be set (perhaps by the BIOS)
>> - whatever else
>>
>> What I'm trying to express is: We simply can't get this right
>> unless we _fully_ emulate family/model/stepping specific
>> behavior (according to the values seen by the guest), with
>> or without migration.
> 
> These registers are completely undocumented.  The only reason we know
> what two of the bits mean is because AMD had to publish them to allow
> OSes to work around the speculative sidechannels.
> 
> This is *also* the reason that AMD published a spec for how virtual
> machines should apply mitigations, giving them an architectural
> interface to specifically avoid them trying to access these CFG
> registers.  All OSes which know about DE_CFG will use MSR_VIRT_SPEC_CTRL
> in preference, because they've followed AMD's instructions when putting
> together SSBD mitigations.

Seeing what this series is doing, "will use" would need to become
"will eventually use" if you want to not exclude Xen itself from the
picture. Are you sure no-one else has taken a shortcut as first
mitigation step?

> Irrespective of the specifics in this case, Xen's behaviour for unknown
> MSRs is reprehensible.  They should not be default readable (there is
> still a case where windows will BSOD on migrate caused by this), and
> they certainly shouldn't be write-silent-discard because it breaks code
> which (correctly) uses wrmsr_safe() to probe for the availability of the
> MSR.

I'm not putting under question this aspect, we're in agreement
here. What we appear to disagree about is the (apparent) claim
of yours that all is going to be well as soon as we stop this bad
but inherited behavior.

Jan



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