Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3578122pxb; Mon, 25 Jan 2021 22:08:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJwuIJG1DNI9WzeUSbTKG4DmqsSnw0OFfsjw+2MRbiu5lkpZhkY8735cfawgd5dCWVMil4O8 X-Received: by 2002:a17:906:3101:: with SMTP id 1mr2537464ejx.115.1611641282449; Mon, 25 Jan 2021 22:08:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611641282; cv=none; d=google.com; s=arc-20160816; b=NFXlC0oC9ouljkW7sX+sJMlQZ9F/dbcUlbmc8CvbgrM+5VsizEirRYRSeypiIfIlnX k3Tqq4Gi+d0BKaQImje2wUpflgVGqaB5HySPFTF+yRfjCDTWR/tbHSWltbkFstvn1j8I vsWMAqgAIsea9CgVZab4CoDCrmMDjRjMNdBeLoc2J9a1zIvklbcKR/ujyo5GYSwZqcgX MZj5D/ep/3aS1Ue7Ra6joo1CAWA541S9sNsJqYE6iWHfIHpYJ/e8caPIMGX0sqMXAPoX iSxbRgA5xNlLpqPlbAjnzhNx6R/rcL1Uaz1HsuxB/ShX3fVAVMXDO1TJZmIA/RSvvHQU Z6jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=IZD+dGpJMuaKiBFySlf5qc6OjXdYWk5ceY7IXIWaNrA=; b=yMhN+l2R5L4NAGrePdJ6jaXgsMW3mB9F1N6U7ypV6+NrWFAhsIjEt9sPVWbTVnLW3E khtAZB5FG4xRCktrVZ9uBRmJUgpAbMIjeRzu7jLiVyeKWaQsFYJZDjAlrfPUmzSurs43 6WEOcG6F2cBYjOKmFldAPVpdxp9dE+U6XdIzPalbxkAI6sS8JU3P38ayjxlgCAENxkR5 IUvDkMOJxBML6DPMUgqbiLLa8Zp0q/0Nrzo9UDlxTzULGdH4TaLIrOEXRuiYxnRuTX8i WK0az8YJ4tJIaS/BDT8eTsBN1yczmPbSY9LXPjIvcqsw7z2GpxGh+HOKPClhVcMp75GN +o5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=mu5dcukK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q7si7907672edt.579.2021.01.25.22.07.38; Mon, 25 Jan 2021 22:08:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=mu5dcukK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727224AbhAZGHK (ORCPT + 99 others); Tue, 26 Jan 2021 01:07:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728427AbhAYMwF (ORCPT ); Mon, 25 Jan 2021 07:52:05 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79B75C0613D6; Mon, 25 Jan 2021 03:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=IZD+dGpJMuaKiBFySlf5qc6OjXdYWk5ceY7IXIWaNrA=; b=mu5dcukKGytbgmut4RSw7dYW5p jcb5tnp16OjtgRykfyfz5gM6Dcvxvfy0l8Ql2XjjHmacq88H1SRBUDZzA49ulM4kutjU+0VK5jQ5t nS723mOgAWmB0I0wvGGuVnT9tuEgrTxGokhUpEpSSYtThg6mCJ0/Fdo1N9TF32vKLai9XtwyZmu4/ rUTHV7jKaxH5JlUbT+TV0sn/gaIddu4ScySHHYGa92fn+GEcyP3P585VchE6U0i4hG4OR38Rr18f0 B2ZwNZH5TE4p88Ve/9VJhdKASrdNHY/4OhvapqGRj97q34yGtlHXAElDKADMLIXYX/FkDSn28LE6+ xLtPT5ew==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1l3zo1-0047fH-T7; Mon, 25 Jan 2021 11:13:23 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 76CE43003D8; Mon, 25 Jan 2021 12:13:10 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 401F82B0615F7; Mon, 25 Jan 2021 12:13:10 +0100 (CET) Date: Mon, 25 Jan 2021 12:13:10 +0100 From: Peter Zijlstra To: Like Xu Cc: Sean Christopherson , Andi Kleen , "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 Subject: Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS Message-ID: References: <20210104131542.495413-1-like.xu@linux.intel.com> <20210115182700.byczztx3vjhsq3p3@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2021 at 04:08:22PM +0800, Like Xu wrote: > 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. Right, but given there is no atomicity between writing the DS area and triggering the PMI (as already established earlier in this thread), a malicious guest can already access this information, no?