On 06/01/2019 03:59 AM, Eric Hankland wrote:
With anythread=0, I'm not aware of any events that directly give info
about other VMs, but monitoring events related to shared resources
(e.g. LLC References and LLC Misses) could indirectly give you info
about how heavily other users are using that resource.
My question is that have we proved that this indirect info leakage
indeed happens?
The spec states that the counter will count the related events generated by
the logical CPU with AnyThread=0. I would be inclined to trust the
hardware behavior
documented in the spec unless we could prove there is a problem.
I tried returning 1 when the guest tries to write the eventsel msr for
a disallowed event - the behavior on modern guest kernels looks
reasonable (warns once about an unchecked MSR access error), but it
looks like guests using older kernels (older than 2016) might panic
due to the gpfault (not to mention I'm not sure about the behavior on
non-linux kernels). So I'm hesitant to return 1 - what do you think?
From the guest point of view, returning 0 means that the event counting
is running well.
That is, the guest is expecting to get some count numbers. So better not
to zero the value
when the guest does rdpmc/rdmsr to get the count in this case.
I think we could just ensure "AnyThread=0" in the config, and create the
kernel
counter as usual.
I also looked into moving from a vcpu ioctl to a vm ioctl - I can send
out a version of the patch with this change once we settle on the
other issues. It will involve some extra locking every time the
counters are programmed to ensure the whitelist or blacklist isn't
removed during access.
Yes, the above discussion needs to be done first.
Best,
Wei
