* 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_. 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 -- 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
