On 19/06/2020 13:57, Michał Leszczyński wrote: > ----- 19 cze 2020 o 14:49, Jan Beulich [email protected] napisał(a): > >> On 19.06.2020 14:10, Michał Leszczyński wrote: >>> ----- 19 cze 2020 o 13:58, Andrew Cooper [email protected] >>> napisał(a): >>> >>>> We do not expose the feature to guests, so should disallow access to the >>>> respective MSRs. >>>> >>>> Signed-off-by: Andrew Cooper <[email protected]> >>>> --- >>>> CC: Jan Beulich <[email protected]> >>>> CC: Wei Liu <[email protected]> >>>> CC: Roger Pau Monné <[email protected]> >>>> CC: Paul Durrant <[email protected]> >>>> CC: Michał Leszczyński <[email protected]> >>>> >>>> Paul: For 4.14. This needs backporting to older trees as well. >>>> >>>> Michał: CC'ing, just to keep you in the loop. Xen has some dubious default >>>> MSR semantics which we're still in the middle of untangling in a backwards >>>> compatible way. Patches like this will eventually not be necessary, but >>>> they >>>> are for now. >>> >>> As for external IPT monitoring, it would be best if the VM would think >>> that IPT is simply not supported at all by the underlying hypervisor. >> This is already the case, isn't it? Yet not reporting a feature may >> not keep a guest from trying to access the respective MSRs. >> >> Jan > > Okay, understood :)
Hiding bits in CPUID doesn't magically make the feature disappear out of the pipeline. Some things we can effectively disable (using suitable intercepts to audit changes to control registers), but for most instruction groups, its trivial to discover if the pipeline supports them, via fault analysis. Despite the software manuals being clear on the matter, not all code checks CPUID properly before poking features. If anything in your VM does do this, then it is likely to crash on migrate, so wherever possible, block access at all levels, not just in CPUID. (Windows DRM/Anti-cheat systems seem to have a particular knack for finding features we haven't disabled properly, and architectural corner cases we don't cope with correctly.) ~Andrew
