>>> On 23.02.19 at 00:48, <boris.ostrov...@oracle.com> wrote: > On 2/22/19 5:44 PM, Andrew Cooper wrote: >> On 22/02/2019 21:58, Boris Ostrovsky wrote: >>> 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 <andrew.coop...@citrix.com> >>>> --- >>>> CC: Jan Beulich <jbeul...@suse.com> >>>> CC: Wei Liu <wei.l...@citrix.com> >>>> CC: Roger Pau Monné <roger....@citrix.com> >>>> CC: Jun Nakajima <jun.nakaj...@intel.com> >>>> CC: Kevin Tian <kevin.t...@intel.com> >>>> CC: Boris Ostrovsky <boris.ostrov...@oracle.com> >>>> CC: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> >>>> CC: Brian Woods <brian.wo...@amd.com> >>>> CC: Juergen Gross <jgr...@suse.com> >>>> >>>> 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.
I don't really understand why you say this - Boris certainly has a point ... >>> When VPMU is off MSR reads return zero. >> That behaviour isn't long for this world. >> >>> While it is debatable whether this the right action, shouldn't rdpmc behave >>> in the same fashion? >> I specifically don't want to propagate the "lets complete with zero" >> behaviour further, because it takes away #GP faults which the guest >> would otherwise get. > > The guest should get a #GP on Intel if CPUID is not reporting any > counters but not on AMD where the first 4 counters are architectural. ... here. For Intel, afaics, we indeed produce a blank CPUID leaf in all cases, so the behavior looks reasonably consistent. I would question though whether a blank CPUID leaf / the absence of any counters wouldn't call for #UD instead of #GP(0). Otherwise, along the lines of AMD, aren't the first two indexes uniformly valid for Intel? Additionally aren't you invoking vpmu_available() before the data it examines actually got set? Afaics vpmu_initialise() gets called after hvm_vcpu_initialise(), yet the latter is where you add the intercept enabling. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel