LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Hankland <ehankland@google.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: pbonzini@redhat.com, rkrcmar@redhat.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist
Date: Tue, 28 May 2019 11:14:12 -0700	[thread overview]
Message-ID: <CAOyeoRWhfyuuYdguE6Wrzd7GOdow9qRE4MZ4OKkMc5cdhDT53g@mail.gmail.com> (raw)
In-Reply-To: <5CEC9667.30100@intel.com>

On Mon, May 27, 2019 at 6:56 PM Wei Wang <wei.w.wang@intel.com> wrote:
>
> On 05/23/2019 06:23 AM, Eric Hankland wrote:
> > - Add a VCPU ioctl that can control which events the guest can monitor.
> >
> > Signed-off-by: ehankland <ehankland@google.com>
> > ---
> > Some events can provide a guest with information about other guests or the
> > host (e.g. L3 cache stats); providing the capability to restrict access
> > to a "safe" set of events would limit the potential for the PMU to be used
> > in any side channel attacks. This change introduces a new vcpu ioctl that
> > sets an event whitelist. If the guest attempts to program a counter for
> > any unwhitelisted event, the kernel counter won't be created, so any
> > RDPMC/RDMSR will show 0 instances of that event.
>
> The general idea sounds good to me :)
>
> For the implementation, I would have the following suggestions:
>
> 1) Instead of using a whitelist, it would be better to use a blacklist to
> forbid the guest from counting any core level information. So by default,
> kvm maintains a list of those core level events, which are not supported to
> the guest.
>
> The userspace ioctl removes the related events from the blacklist to
> make them usable by the guest.
>
> 2) Use vm ioctl, instead of vcpu ioctl. The blacklist-ed events can be
> VM wide
> (unnecessary to make each CPU to maintain the same copy).
> Accordingly, put the pmu event blacklist into kvm->arch.
>
> 3) Returning 1 when the guest tries to set the evetlsel msr to count an
> event which is on the blacklist.
>
> Best,
> Wei

Thanks for the feedback. I have a couple concerns with a KVM
maintained blacklist. First, I'm worried it will be difficult to keep
such a list up to date and accurate (both coming up with the initial
list since there are so many events, and updating it whenever any new
events are published or vulnerabilities are discovered). Second, users
may want to differentiate between whole-socket and sub-socket VMs
(some events may be fine for the whole-socket case) - keeping a single
blacklist wouldn't allow for this. Let me know what you think. I'll
try implementing the other suggestions.
-Eric

  reply	other threads:[~2019-05-28 18:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 22:23 Eric Hankland
2019-05-28  2:01 ` Wei Wang
2019-05-28 18:14   ` Eric Hankland [this message]
2019-05-29  7:54     ` Wei Wang
2019-05-29 17:11       ` Eric Hankland
2019-05-31  1:02         ` Wei Wang
2019-05-31 19:59           ` Eric Hankland
2019-06-01 10:55             ` Wei Wang
2019-06-03 17:30               ` Eric Hankland
2019-06-04  4:42                 ` Wei Wang
2019-06-04 15:56                   ` Eric Hankland
     [not found]                     ` <CAEU=KTHsVmrAHXUKdHu_OwcrZoy-hgV7pk4UymtchGE5bGdUGA@mail.gmail.com>
2019-06-05 21:35                       ` Eric Hankland
2019-06-06  7:36                         ` Wei Wang
2019-06-13 17:43                           ` Eric Hankland
2019-06-14  9:14                             ` Wei Wang
2019-06-14  9:26 ` Wei Wang
2019-06-25  0:32   ` Eric Hankland
2019-06-25  9:12     ` Wei Wang
2019-07-02 17:46       ` Eric Hankland
2019-07-03  9:06         ` Wei Wang
2019-06-20 18:05 ` Andi Kleen
2019-06-24 23:56   ` Eric Hankland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOyeoRWhfyuuYdguE6Wrzd7GOdow9qRE4MZ4OKkMc5cdhDT53g@mail.gmail.com \
    --to=ehankland@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=wei.w.wang@intel.com \
    --subject='Re: [PATCH v1] KVM: x86: PMU Whitelist' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).