Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

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.