lkml.org 
[lkml]   [2019]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v1] KVM: x86: PMU Whitelist
On Sat, Jun 1, 2019 at 3:50 AM Wei Wang <wei.w.wang@intel.com> wrote:
>
> My question is that have we proved that this indirect info leakage
> indeed happens?
> The spec states that the counter will count the related events generated by
> the logical CPU with AnyThread=0. I would be inclined to trust the
> hardware behavior
> documented in the spec unless we could prove there is a problem.

I'm not disputing the spec with regards to AnyThread=0; my point is
that LLC contention can be quantified using the PMU regardless of
whether or not you are measuring only the logical CPU you are running
on.

> From the guest point of view, returning 0 means that the event counting
> is running well.
> That is, the guest is expecting to get some count numbers. So better not
> to zero the value
> when the guest does rdpmc/rdmsr to get the count in this case.
>
> I think we could just ensure "AnyThread=0" in the config, and create the
> kernel
> counter as usual.

If you return non-zero in intel_pmu_set_msr(), KVM emulates a gp
fault. Which as you said signals that something went wrong to the
guest. However, older guests with panic_on_oops=1 (which is apparently
default on RHEL 6) will panic if they get a gpfault while trying to do
a wrmsr (see the "Carry on after a non-"safe" MSR access fails without
!panic_on_oops" patch). I think that not panicking guests is probably
preferable to communicating that we weren't able to program the event.


Eric

\
 
 \ /
  Last update: 2019-06-03 19:31    [W:0.127 / U:3.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site