From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 633EAC28CC1 for ; Sat, 1 Jun 2019 10:50:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4199827223 for ; Sat, 1 Jun 2019 10:50:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727269AbfFAKuS (ORCPT ); Sat, 1 Jun 2019 06:50:18 -0400 Received: from mga12.intel.com ([192.55.52.136]:44926 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbfFAKuR (ORCPT ); Sat, 1 Jun 2019 06:50:17 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2019 03:50:16 -0700 X-ExtLoop1: 1 Received: from unknown (HELO [10.239.13.7]) ([10.239.13.7]) by orsmga007.jf.intel.com with ESMTP; 01 Jun 2019 03:50:15 -0700 Message-ID: <5CF2599B.3030001@intel.com> Date: Sat, 01 Jun 2019 18:55:23 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Hankland CC: pbonzini@redhat.com, rkrcmar@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist References: <5CEC9667.30100@intel.com> <5CEE3AC4.3020904@intel.com> <5CF07D37.9090805@intel.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 06/01/2019 03:59 AM, Eric Hankland wrote: > > With anythread=0, I'm not aware of any events that directly give info > about other VMs, but monitoring events related to shared resources > (e.g. LLC References and LLC Misses) could indirectly give you info > about how heavily other users are using that resource. 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 tried returning 1 when the guest tries to write the eventsel msr for > a disallowed event - the behavior on modern guest kernels looks > reasonable (warns once about an unchecked MSR access error), but it > looks like guests using older kernels (older than 2016) might panic > due to the gpfault (not to mention I'm not sure about the behavior on > non-linux kernels). So I'm hesitant to return 1 - what do you think? 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. > I also looked into moving from a vcpu ioctl to a vm ioctl - I can send > out a version of the patch with this change once we settle on the > other issues. It will involve some extra locking every time the > counters are programmed to ensure the whitelist or blacklist isn't > removed during access. > Yes, the above discussion needs to be done first. Best, Wei