From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 15:53:51 +0200 Message-ID: <4B87D26F.7080703@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> <4B87C354.9020209@redhat.com> <20100226130656.GA2518@elte.hu> <4B87CCF5.6000209@redhat.com> <20100226134400.GB23422@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , Joerg Roedel , KVM General , Peter Zijlstra , Zachary Amsden , Gleb Natapov , ming.m.lin@intel.com, "Zhang, Yanmin" , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , Arjan van de Ven , Fr??d??ric Weisbecker , Arnaldo Carvalho de Melo To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37791 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936217Ab0BZNyn (ORCPT ); Fri, 26 Feb 2010 08:54:43 -0500 In-Reply-To: <20100226134400.GB23422@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:44 PM, Ingo Molnar wrote: > * Avi Kivity 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.