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 303DCC433DF for ; Wed, 17 Jun 2020 09:21:32 +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 07EC7208B3 for ; Wed, 17 Jun 2020 09:21:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07EC7208B3 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 1jlUFt-0007ZU-Qi; Wed, 17 Jun 2020 09:21:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUFs-0007ZP-CN for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:21:12 +0000 X-Inumbo-ID: e216d2da-b07b-11ea-bca7-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e216d2da-b07b-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 09:21:11 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QTHvT4+wjw8k8S/o0nb4H+k3beeiN6CrswUQWjCGDmVPBmFDnKn4RziYsXwS3M8fLhka54ezPT T1He5jaDeLIgC2LEGIXyzZ9EVunhgEsJl+5G9rNoopBNTmpIR7id4VeQwQ9BNEKBmldTjgHHKd EyRcYg36xtr2pX09FptE9LM85AmkqRyHUT1z4QxCn1kclSFlhzL2Pnl/Pq2Wdea61xbYdJ8nHT iiARxx0MYapjnShPoQVjI+pRMXvRc005ejVqzm390KJkp5k9+2FQwl2HGFyqMADj3DY0Um9+rA N4Q= X-SBRS: 2.7 X-MesageID: 20264108 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20264108" Date: Wed, 17 Jun 2020 11:21:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: "Kang, Luwei" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200617092103.GZ735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.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: 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: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 06:45:22AM +0000, Kang, Luwei wrote: > > -----Original Message----- > > From: Tian, Kevin > > Sent: Wednesday, June 17, 2020 9:35 AM > > To: Michał Leszczyński ; Andrew Cooper > > > > Cc: Xen-devel ; Jan Beulich > > ; Wei Liu ; Roger Pau Monné > > ; Nakajima, Jun ; George > > Dunlap ; Ian Jackson ; > > Julien Grall ; Stefano Stabellini ; > > Kang, Luwei > > Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring > > > > +Luwei, who developed PT for KVM and is the best one who can help > > review VMX changes from Intel side. Please include him in future post or > > discussion. > > > > > -----Original Message----- > > > From: Michał Leszczyński > > > Sent: Wednesday, June 17, 2020 2:48 AM > > > To: Andrew Cooper > > > Cc: Xen-devel ; Jan Beulich > > > ; Wei Liu ; Roger Pau Monné > > > ; Nakajima, Jun ; Tian, > > > Kevin ; George Dunlap > > > ; Ian Jackson ; > > > Julien Grall ; Stefano Stabellini > > > > > > Subject: Re: [PATCH v1 0/7] Implement support for external IPT > > > monitoring > > > > > > ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com > > > napisał(a): > > > > > > > On 16/06/2020 16:16, Michał Leszczyński wrote: > > > > When this subject was broached on xen-devel before, one issue was > > > > the fact that all actions which are intercepted don't end up writing > > > > any appropriate packets.  This is perhaps less of an issue for this > > > > example, where the external agent can see VMExits in the trace, but > > > > it still results in missing information.  (It is a major problem for > > > > PT within the guest, and needs Xen's intercept/emulation framework > > > > being updated to be PT-aware so it can fill in the same packets > > > > which hardware would have done for equivalent actions.) > > > > > > Ok, this sounds like a hard issue. Could you point out what could be > > > the particular problematic cases? For instance, if something would > > > alter EIP/RIP or CR3 then I belive it would still be recorded in PT > > > trace (i.e. these values will be logged on VM entry). > > e.g. If a VM exit is taken on a guest write to CR3 (including “MOV CR3” as well as task switches), the PIP packet > normally generated on the CR3 write will be missing. The PIP packet needs to be written to the PT buffer by software. Another example is VM-exit taken on RDTSC. > > For VM introspection, all the Intel PT packets may need to emulated by software. Some description in SDM as below: > If a VMM emulates an element of processor state by taking a VM exit on reads and/or writes to that piece of state, and the state element impacts Intel PT packet generation or values, it may be incumbent upon the VMM to insert or modify the output trace data. I got the impression that IPT was mostly useful together with introspection, as you can then get events from trapped instructions (and likely emulated) from the introspection interface, while being able to get the processor trace for non-trapped events. I'm not sure whether there would be corner cases with trapped instructions not being handled by the introspection framework. How does KVM deal with this, do they insert/modify trace packets on trapped and emulated instructions by the VMM? Roger.