Re: [Xen-devel] [PATCH] x86/hvm: Intercept RDPMC when vPMU is disabled

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.19 at 00:48, <boris.ostrovsky@xxxxxxxxxx> 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.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
>>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> CC: Jun Nakajima <jun.nakajima@xxxxxxxxx>
>>>> CC: Kevin Tian <kevin.tian@xxxxxxxxx>
>>>> CC: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>>>> CC: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
>>>> CC: Brian Woods <brian.woods@xxxxxxx>
>>>> CC: Juergen Gross <jgross@xxxxxxxx>
>>>>
>>>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel