On 02/26/2010 03:44 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> 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_.
You mean like bus transactions on a multicore? Well, we're already
exposed to cache timing attacks.
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.
What about Windows?
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)
Why not? So long as the source and destination are compatible?
- 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.
Right, time slicing is something we want.
- 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.
No, we can hide insecure events with a full pmu. Trap the control
register and don't pass it on to the hardware.
- 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.
But it is limited to whatever the host stack supports. At least that's
our control, but things like PEBS will take a ton of work.
- 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.
We only control half of the equation. That's very different compared to
tools/perf.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
