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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 D201CC433E0 for ; Mon, 25 Jan 2021 08:59:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B04E22D57 for ; Mon, 25 Jan 2021 08:59:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725868AbhAYI6l (ORCPT ); Mon, 25 Jan 2021 03:58:41 -0500 Received: from mga18.intel.com ([134.134.136.126]:6125 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbhAYIl5 (ORCPT ); Mon, 25 Jan 2021 03:41:57 -0500 IronPort-SDR: Nkcf3k0VB3i9oL8GLtTcasCPxzZvIqI28JAjnyptGYc83wKlpjajBLGIrdxvMmTLXeLCbd3xr9 QKqXF/iwbtDw== X-IronPort-AV: E=McAfee;i="6000,8403,9874"; a="167358140" X-IronPort-AV: E=Sophos;i="5.79,372,1602572400"; d="scan'208";a="167358140" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2021 00:08:30 -0800 IronPort-SDR: +yed1xN/jKxYgQSYnlV82Hldq/lmX9jM0EfNi8kT917T/sfidv4AAiqvN61YAqMDp2sAgl/AF+ ucNkTjPGuIeg== X-IronPort-AV: E=Sophos;i="5.79,372,1602572400"; d="scan'208";a="387230072" Received: from likexu-mobl1.ccr.corp.intel.com (HELO [10.238.4.93]) ([10.238.4.93]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2021 00:08:26 -0800 Subject: Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS To: Peter Zijlstra , Sean Christopherson , Andi Kleen Cc: "Xu, Like" , Kan Liang , Paolo Bonzini , eranian@google.com, kvm@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , wei.w.wang@intel.com, luwei.kang@intel.com, linux-kernel@vger.kernel.org References: <20210104131542.495413-1-like.xu@linux.intel.com> <20210115182700.byczztx3vjhsq3p3@two.firstfloor.org> From: Like Xu Organization: Intel OTC Message-ID: Date: Mon, 25 Jan 2021 16:08:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Peter, On 2021/1/22 17:56, Peter Zijlstra wrote: > On Fri, Jan 15, 2021 at 10:51:38AM -0800, Sean Christopherson wrote: >> On Fri, Jan 15, 2021, Andi Kleen wrote: >>>> I'm asking about ucode/hardare. Is the "guest pebs buffer write -> PEBS PMI" >>>> guaranteed to be atomic? >>> >>> Of course not. >> >> So there's still a window where the guest could observe the bad counter index, >> correct? > > Guest could do a hypercall to fix up the DS area before it tries to read > it I suppose. Or the HV could expose the index mapping and have the > guest fix up it. A weird (malicious) guest would read unmodified PEBS records in the guest PEBS buffer from other vCPUs without the need for hypercall or index mapping from HV. Do you see any security issues on this host index leak window? > > Adding a little virt crud on top shouldn't be too hard. > The patches 13-17 in this version has modified the guest PEBS buffer to correct the index mapping information in the guest PEBS records. --- thx,likexu