Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAOyeoRWfPNmaWY6Lifdkdj3KPPM654vzDO+s3oduEMCJP+Asow@mail.gmail.com>
 <5CEC9667.30100@intel.com> <CAOyeoRWhfyuuYdguE6Wrzd7GOdow9qRE4MZ4OKkMc5cdhDT53g@mail.gmail.com>
 <5CEE3AC4.3020904@intel.com> <CAOyeoRW85jV=TW_xwSj0ZYwPj_L+G9wu+QPGEF3nBmPbWGX4_g@mail.gmail.com>
 <5CF07D37.9090805@intel.com> <CAOyeoRXWQaVYZSVL_LTTdAwJOEr+eCzhp1=_JcOX3i6_CJiD_g@mail.gmail.com>
 <5CF2599B.3030001@intel.com>
In-Reply-To: <5CF2599B.3030001@intel.com>
From:   Eric Hankland <ehankland@google.com>
Date:   Mon, 3 Jun 2019 10:30:20 -0700
Message-ID: <CAOyeoRWuHyhoy6NB=O+ekQMhBFngozKoanWzArxgBk4DH2hdtg@mail.gmail.com>
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist
To:     Wei Wang <wei.w.wang@intel.com>
Cc:     pbonzini@redhat.com, rkrcmar@redhat.com,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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