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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9D36FC433E0 for ; Thu, 18 Jun 2020 07:01:09 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7491320706 for ; Thu, 18 Jun 2020 07:01:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7491320706 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloXZ-0003eD-3t; Thu, 18 Jun 2020 07:00:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloXY-0003e8-7U for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 07:00:48 +0000 X-Inumbo-ID: 6f38d2e8-b131-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6f38d2e8-b131-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 07:00:47 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: BaySQT8b1hKl0fkjL+lkUs3P1OxEcaeZTre6McMWNud+f3RNJskv9tlaBBtYkHLwBYG8JAardi UpgY8wsfKK0oaioTxdAfPRghFbVArxrGLfLhAZPDlXKyTirGQOz/7Rw9Ydy2V/zVk9q2Q8NJWk v0AziURMk/BI6jSr1+NQ4K8Zg8ZQwgcXl+VGSk1i26lNYYpZK7jCX/6gUZb+puhKSjSJbbz2HL DjsIXlTZ0LcwACripx81wFY0uaXpBMP/a5vSZaEwUrJ3U16D6ynNSAFSei6dHA+XYuNFVgg0py /Wg= X-SBRS: 2.7 X-MesageID: 20569672 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,525,1583211600"; d="scan'208";a="20569672" Date: Thu, 18 Jun 2020 09:00:35 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200618070035.GD735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> <20200617125339.GB735@Air-de-Roger> <1683804232.9278740.1592441777496.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1683804232.9278740.1592441777496.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , "Tian, Kevin" , Stefano Stabellini , "Kang, Luwei" , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 02:56:17AM +0200, Michał Leszczyński wrote: > ----- 18 cze 2020 o 1:29, Kang, Luwei luwei.kang@intel.com napisał(a): > > >> > > How does KVM deal with this, do they insert/modify trace packets on > >> > > trapped and emulated instructions by the VMM? > >> > > >> > The KVM includes instruction decoder and > >> emulator(arch/x86/kvm/emulate.c), and the guest's memory can be set to > >> write-protect as well. But it doesn't support Intel PT packets software > >> emulator. > >> For KVM, the Intel PT feature will be exposed to KVM guest and KVM guest can > >> use Intel PT feature like native. > >> > >> But if such feature is exposed to the guest for it's own usage, won't it be > >> missing packets for instructions emulated by the VMM? > > > > If setting the guest's memory write-protect, I think yes. > > > Thus, I propose to leave it as it is right now. If somebody is purposely altering the VM state then he/she should consult not only the IPT but also understand what was done "in the meantime" by additional features, e.g. when something was altered by vm_event callback. As Tamas said previously, we usually just want to see certain path leading to vmexit. > > Please also note that there is a PTWRITE instruction that could be used in the future in order to add custom payloads/hints to the PT trace, when needed. Yes, I think the usage of IPT by a third party against a guest is fine, as such third party can also use introspection and get the information about the emulated instructions. OTOH exposing the feature to the guest itself for it's own usage seems wrong without adding the packets related to the instructions emulated. I understand the current series only cares about the first option, so that's perfectly fine. Roger.