LKML Archive on
help / color / mirror / Atom feed
From: Wei Wang <>
To: Eric Hankland <>
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist
Date: Fri, 31 May 2019 09:02:47 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 05/30/2019 01:11 AM, Eric Hankland wrote:
> On Wed, May 29, 2019 at 12:49 AM Wei Wang <> wrote:
>> On 05/29/2019 02:14 AM, Eric Hankland wrote:
>>> On Mon, May 27, 2019 at 6:56 PM Wei Wang <> 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 <>
>>>>> ---
>>>>> 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).
>> Not sure about "so many" above. I think there should be much
>> fewer events that may need to be blacklisted.
>> For example the event table 19-3 from SDM 19.2 shows hundreds of
>> events, how many of them would you think that need to be blacklisted?
>>> 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.
>> Why wouldn't?
>> In any case (e.g. the whole socket dedicated to the single VM) we
>> want to unlock the blacklisted events, we can have the userspace
>> (e.g. qemu command line options "+event1, +event2") do ioctl to
>> have KVM do that.
>> Btw, for the L3 cache stats event example, I'm not sure if that could
>> be an issue if we have "AnyThread=0". I'll double confirm with
>> someone.
>> Best,
>> Wei
>> Not sure about "so many" above. I think there should be much
>> fewer events that may need to be blacklisted.
> I think you're right that there are not as many events that seem like
> they could leak info as events that seem like they won't, but I think
> the work to validate that they definitely don't could be expensive;
> with a whitelist it's easy to start with a smaller set and
> incrementally add to it without having to evaluate all the events
> right away.

Before going that whitelist/blacklist direction, do you have an event
example that couldn't be solved by setting "AnyThread=0"?

If no, I think we could simply gate guest's setting of "AnyThread=0".


  reply	other threads:[~2019-05-31  0:57 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
2019-05-29  7:54     ` Wei Wang
2019-05-29 17:11       ` Eric Hankland
2019-05-31  1:02         ` Wei Wang [this message]
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]                     ` <>
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:

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

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v1] KVM: x86: PMU Whitelist' \

* 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).