On 2/22/19 4:13 PM, Andrew Cooper wrote: > vPMU isn't security supported, and in general guests can't access any of the > performance counter MSRs. However, the RDPMC instruction isn't intercepted, > meaning that guest software can read the instantaneous counter values. > > When vPMU isn't configured, intercept RDPMC and unconditionally fail it as if > software has requested a bad counter index (#GP fault). It is model specific > as to which counters are available to begin with, and in levelled scenarios, > this information may not be accurate in the first place. > > This change isn't expected to have any impact on VMs. Userspace is not > usually given access to RDPMC (Windows appear to completely prohibit it; Linux > is restricted to root), and kernels won't be executing RDPMC instructions if > their PMU drivers have failed to start. > > Signed-off-by: Andrew Cooper <[email protected]> > --- > CC: Jan Beulich <[email protected]> > CC: Wei Liu <[email protected]> > CC: Roger Pau Monné <[email protected]> > CC: Jun Nakajima <[email protected]> > CC: Kevin Tian <[email protected]> > CC: Boris Ostrovsky <[email protected]> > CC: Suravee Suthikulpanit <[email protected]> > CC: Brian Woods <[email protected]> > CC: Juergen Gross <[email protected]> > > This should be taken into Xen 4.12 and backported to the stable releases. > While it isn't an XSA itself, it is an information leak (Xen's NMI watchdog in > particular) which could be advantagous to an attacker trying to exploit a race > condition. > > The only other option is to emulate the reported family and offer back all 0's > for the accessable counters. Obviously this is a non-starter.
When VPMU is off MSR reads return zero. While it is debatable whether this the right action, shouldn't rdpmc behave in the same fashion? -boris _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
