Re: KVM PMU virtualization

Avi Kivity
2010-02-26T13:54:43Z

On 02/26/2010 03:44 PM, Ingo Molnar wrote:
> * 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_.
>

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.