Re: KVM PMU virtualization

Ingo Molnar
2010-02-26T13:44:19Z

* Avi Kivity <avi@redhat.com> wrote:

> On 02/26/2010 03:06 PM, Ingo Molnar wrote:
> >
> >>>Firstly, an emulated PMU was only the second-tier option i suggested. By far
> >>>the best approach is native API to the host regarding performance events and
> >>>good guest side integration.
> >>>
> >>>Secondly, the PMU cannot be 'given' to the guest in the general case. Those
> >>>are privileged registers. They can expose sensitive host execution details,
> >>>etc. etc. So if you emulate a PMU you have to exit out of most PMU accesses
> >>>anyway for a secure solution. (RDPMC can still be supported, but in close
> >>>cooperation with the host)
> >>There is nothing secret in the host PMU, and it's easy to clear out the
> >>counters before passing them off to the guest.
> >That's wrong. On some CPUs the host PMU can be used to say sample aspects of
> >another CPU, allowing statistical attacks to recover crypto keys. It can be
> >used to sample memory access patterns of another node.
> >
> >There's a good reason PMU configuration registers are privileged and there's
> >good value in only giving a certain sub-set to less privileged entities by
> >default.
>
> Even if there were no security considerations, if the guest can observe host
> data in the pmu, it means the pmu is inaccurate. We should expose guest
> data only in the guest pmu. That's not difficult to do, you stop the pmu on
> exit and swap the counters on context switches.

Again you are making an incorrect assumption: that information leakage via the
PMU only occurs while the host is running on that CPU. It does not - the PMU
can leak general system details _while the guest is running_.

So for this and for the many other reasons we dont want to give a raw PMU to
guests:

- A paravirt event driver is more compatible and more transparent in the long
run: it allows hardware upgrade and upgraded PMU functionality (for Linux)
without having to upgrade the guest OS. Via that a guest OS could even be
live-migrated to a different PMU, without noticing anything about it.

In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS
always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state
cannot be live-migrated. (save/restore doesnt help)

- It's far cleaner on the host side as well: more granular, per event usage
is possible. The guest can use portion of the PMU (managed by the host),
and the host can use a portion too.

In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS
precludes the host OS from running some different piece of instrumentation
at the same time.

- It's more secure: the host can have a finegrained policy about what kinds of
events it exposes to the guest. It might chose to only expose software
events for example.

In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS is
an all-or-nothing policy affair: either you fully allow the guest (and live
with whatever consequences the piece of hardware that takes up a fair chunk
on the CPU die causes), or you allow none of it.

- A proper paravirt event driver gives more features as well: it can exposes
host software events and tracepoints, probes - not restricting itself to
the 'hardware PMU' abstraction.

- There's proper event scheduling and event allocation. Time-slicing, etc.

The thing is, we made quite similar arguments in the past, during the perfmon
vs. perfcounters discussions. There's really a big advantage to proper
abstractions, both on the host and on the guest side.

Ingo