On 04/12/2018 12:45, Jan Beulich wrote: >>>> On 04.12.18 at 12:26, <andrew.coop...@citrix.com> 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. 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel