From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH] vm_event: Implement ARM SMC events Date: Wed, 13 Apr 2016 09:32:48 -0600 Message-ID: References: <1460404042-31179-1-git-send-email-tamas@tklengyel.com> <570CA910.8050404@bitdefender.com> <570D2135.1040204@arm.com> <570D2AC3.2040801@bitdefender.com> <570E0967.3070600@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2018594213188577411==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMmh-0000hA-3c for xen-devel@lists.xenproject.org; Wed, 13 Apr 2016 15:32:51 +0000 Received: by mail-wm0-f54.google.com with SMTP id v188so181525081wme.1 for ; Wed, 13 Apr 2016 08:32:49 -0700 (PDT) In-Reply-To: <570E0967.3070600@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Corneliu ZUZU Cc: Wei Liu , Keir Fraser , Razvan Cojocaru , Stefano Stabellini , Andrew Cooper , Ian Jackson , Julien Grall , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org --===============2018594213188577411== Content-Type: multipart/alternative; boundary=001a1141f1547bee9905305f7df2 --001a1141f1547bee9905305f7df2 Content-Type: text/plain; charset=UTF-8 > > > >>> >>>> I would have to double check but AFAIK those instructions can't be >>>> configured to trap to the hypervisor directly. So while SMC was not >>>> intended to be a breakpoint, conceptually it's the closest thing we have >>>> an on ARM to the INT3 instruction when configured to trap to the VMM. >>>> >>> >>> >> Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since >> activating this bit would imply additional (in this context -unwanted-) >> traps, the performance hit of having this bit set might be significant. >> > > Right, actually I believe KVM already implemented this, I was just under > the impression it was only for aarch64. As for performance overhead I'm not > that worried about it, rather I need to make sure the presence of the > monitoring can remain stealthy. I know on KVM for example this type of > trapping renders the guest to be unable to use singlestepping, which would > easily reveal the presence of the external monitor (see > https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014589.html). So > this will need to be looked at carefully. > > > That seems to apply to single-stepping only, which would be a different > matter. > If you read the commit message on the previous patch in that thread that actually enables TDE trapping ( https://lists.cs.columbia.edu/pipermail/kvmarm/2015-May/014621.html) it says: "Any other guest software debug exception (e.g. single step or HW assisted breakpoints) will cause an error and the VM to be killed." So it sounds to me singlestep on ARM is also routed as a software debug exception and thus would be trapped (again, I would need to double-check the manual). The follow up patch I linked earlier implements handling it but requires the supression of the guest being able to singlestep itself. We might be able to work around that if we can reinject the singlestep exception to the guest. So all I'm saying is that this needs to be looked at carefully as there may be issues there, especially for the use-case I have in mind. And while having singlestepping trap to the hypervisor is very handy I actually have a better method to hide the presence of say injected SMCs, albeit it requires altp2m. Fortunately we have some students who proposed implementing it this summer through the Honeynet Project's Google Summer of Code ;) Tamas --001a1141f1547bee9905305f7df2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



I would have to double check but AFAIK those instructions can't be
configured to trap to the hypervisor directly. So while SMC was not
intended to be a breakpoint, conceptually it's the closest thing we have
an on ARM to the INT3 instruction when configured to trap to the VMM.


 Please see AArch32 HDCR.TDE and AArch64 MDCR_EL2.TDE bits. Since activating this bit would imply additional (in this context -unwanted-) traps, the performance hit of having this bit set might be significant.

Right, actually I believe KVM already implemented this, I was just under the impression it was only for aarch64. As for performance overhead I'm not that worried about it= , rather I need to make sure the presence of the monitoring can remain stealthy. I know on KVM for example this type of trapping renders the guest to be unable to use singlestepping, which would easily reveal the presence of the external monitor (see https://list= s.cs.columbia.edu/pipermail/kvmarm/2015-May/014589.html). So this will need to be looked at carefully.

That seems to apply to single-stepping only, which would be a different matter.

If you read= the commit message on the previous patch in that thread that actually enab= les TDE trapping (https://lists.cs.columbia.edu/pipermail/kvmarm/2015-= May/014621.html) it says: "Any other guest software debug exceptio= n (e.g. single step or HW assisted breakpoints) will cause an error and the= VM to be killed." So it sounds to me singlestep on ARM is also routed= as a software debug exception and thus would be trapped (again, I would ne= ed to double-check the manual). The follow up patch I linked earlier implem= ents handling it but requires the supression of the guest being able to sin= glestep itself. We might be able to work around that if we can reinject the= singlestep exception to the guest. So all I'm saying is that this need= s to be looked at carefully as there may be issues there, especially for th= e use-case I have in mind.

And while having singlesteppin= g trap to the hypervisor is very handy I actually have a better method to h= ide the presence of say injected SMCs, albeit it requires altp2m. Fortunate= ly we have some students who proposed implementing it this summer through t= he Honeynet Project's Google Summer of Code ;)

=
Tamas

--001a1141f1547bee9905305f7df2-- --===============2018594213188577411== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============2018594213188577411==--