From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corneliu ZUZU Subject: Re: [PATCH] vm_event: Implement ARM SMC events Date: Wed, 13 Apr 2016 13:53:07 +0300 Message-ID: <570E2513.5060502@bitdefender.com> 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> <570E1CD5.7000802@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2794704041864693367==" 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 1aqIPj-0006Tu-MK for xen-devel@lists.xenproject.org; Wed, 13 Apr 2016 10:52:51 +0000 Received: from smtp02.buh.bitdefender.net (unknown [10.17.80.76]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id E3C067FC09 for ; Wed, 13 Apr 2016 13:52:47 +0300 (EEST) In-Reply-To: <570E1CD5.7000802@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper , Tamas K Lengyel Cc: Wei Liu , Keir Fraser , Razvan Cojocaru , Stefano Stabellini , Ian Jackson , Julien Grall , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============2794704041864693367== Content-Type: multipart/alternative; boundary="------------040009080806080501000406" This is a multi-part message in MIME format. --------------040009080806080501000406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/13/2016 1:17 PM, Andrew Cooper wrote: > On 13/04/16 09:55, Corneliu ZUZU wrote: >> >> >>> >>> >>> 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. As for stealthiness or not limiting the guest, IMO >> that shouldn't be a problem with BKPT/BRK, since I believe you can >> inject the breakpoint exception into the guest as if no hypervisor >> trap occured in between (of course, once you decide whether that >> breakpoint is Xen's or guest-internal). But what about X86? How is >> stealthiness achieved there? Is INT3 entirely not available for the >> guest anymore when guest-debugging is enabled or are ALL INT3's >> reported by Xen as software breakpoint vm-events? > > In x86, attaching a debugger to the domain causes #DB and #BP > exceptions to be intercepted by Xen, rather than handled directly by > the domain (actually, since XSA-156, #DB is intercepted under all > circumstances, to avoid security issues). The debugger receives all > debug events, and should filer the ones it has introduced vs the ones > present from in-guest activities. > > ~Andrew > > (Whether this works or not is a separate matter, and largely depends > on the debugger.) And after this filtering, I guess if the debug event proves to be introduced by in-guest activities, the exception is reintroduced to preserve transparency, correct? I'm curious if behind the scenes Xen also write-protects that page such that the guest does not overwrite the INT3. This approach, I think, could be used w/ BKPT/BRK instructions on ARM as well. After all, BKPT/BRK functionality is precisely that of INT3's with the slight enhancement of having an #imm attached. But, as I said, I anticipate that the actual implementation differences for this vm-event on ARM, if using BKPT/BRK (compared to X86) will emerge due to the fact that on X86 INT3 can be trapped all by itself, whereas on ARM such granularity is not available for BKPT/BRK. Also, working with the debug architecture might prove to be a little bit elaborate. So I guess this is a question of balancing conceptual correctness vs being practical for the short run with far less effort. :-) Corneliu. --------------040009080806080501000406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/13/2016 1:17 PM, Andrew Cooper wrote:
On 13/04/16 09:55, Corneliu ZUZU wrote:




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. As for stealthiness or not limiting the guest, IMO that shouldn't be a problem with BKPT/BRK, since I believe you can inject the breakpoint exception into the guest as if no hypervisor trap occured in between (of course, once you decide whether that breakpoint is Xen's or guest-internal). But what about X86? How is stealthiness achieved there? Is INT3 entirely not available for the guest anymore when guest-debugging is enabled or are ALL INT3's reported by Xen as software breakpoint vm-events?

In x86, attaching a debugger to the domain causes #DB and #BP exceptions to be intercepted by Xen, rather than handled directly by the domain (actually, since XSA-156, #DB is intercepted under all circumstances, to avoid security issues).  The debugger receives all debug events, and should filer the ones it has introduced vs the ones present from in-guest activities.

~Andrew

(Whether this works or not is a separate matter, and largely depends on the debugger.)

And after this filtering, I guess if the debug event proves to be introduced by in-guest activities, the exception is reintroduced to preserve transparency, correct?
I'm curious if behind the scenes Xen also write-protects that page such that the guest does not overwrite the INT3.
This approach, I think, could be used w/ BKPT/BRK instructions on ARM as well. After all, BKPT/BRK functionality is precisely that of INT3's with the slight enhancement of having an #imm attached.
But, as I said, I anticipate that the actual implementation differences for this vm-event on ARM, if using BKPT/BRK (compared to X86) will emerge due to the fact that on X86 INT3 can be trapped all by itself, whereas on ARM such granularity is not available for BKPT/BRK. Also, working with the debug architecture might prove to be a little bit elaborate. So I guess this is a question of balancing conceptual correctness vs being practical for the short run with far less effort. :-)

Corneliu.
--------------040009080806080501000406-- --===============2794704041864693367== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============2794704041864693367==--