From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antony Saba Subject: Re: [Xen-users] xc_hvm_inject_trap() failing for int3 traps under Xen 4.2.2 Date: Mon, 10 Jun 2013 16:57:10 +0000 Message-ID: <51B60565.1080903@mandiant.com> References: <51AE5D82.8090608@mandiant.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Content-ID: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xen.org" , Steven Maresca , "xen-users@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/10/2013 05:29 AM, George Dunlap wrote: > On Fri, Jun 7, 2013 at 4:51 PM, Steven Maresca wrote: >> Tony, >> >> I can confirm INT3 re-injection does work on 4.2.x and 4.3, but the >> problem you observed is certainly present. >> >> As suggested, it was necessary when invoking xc_hvm_inject_trap to >> specify the 1-byte instruction length for 0xCC (without which the VM >> was intentionally crashed by Xen). >> >> In this case, there's no need to inspect the actual instruction >> referenced by the IP because it seems the trap is only fired for the >> one-byte variant (0xCD03 of course works properly, but no event is >> emitted). >> >> Mirroring your experience with 4.1.2, for my testing on 4.2+ the >> return of xc_hvm_inject_trap is also always non-zero even for >> successful re-injection..whether that's intended is another question. >> >> Steve >> >> NOTE: I would definitely consider it a bug that the xen-access.c >> example crashes guests when attempting to use the INT3 >> mode...non-critical for most users, but nevertheless. > > I'm having a bit of trouble finding the conclusion here. > > So it seems the problem is that if a *guest* is doing int3 > instructions, that will interfere with the ability of the debugger to > use int3 to do introspection -- is that right? > Yes, that is one scenario. The one I was experiencing was some (apparently legitimate) background process on a Windows 7 x64 guest that just always executes an int3 when it runs. I'll try to summarize, someone please correct me if I'm wrong. There are 2 things going on here: 1) The patch previously posted by AP is the correct way to call xc_hvm_inject_trap() for int 3 (0xcc). That is, the instruction_length parameter must be set to 1. 2) xc_hvm_inject_trap() always returns a negative value, even when there is not a problem and the guest receives the trap as expected. There hasn't been a clarification as to whether it's supposed to return non-negative, but one would assume that it should because of the way the xen-access.c example checks for it. There was an error in my modifications to xen-access.c to ignore the error from xc_hvm_inject_trap(), which was causing resume_page() to not get called, resulting in a frozen guest on my machines. Thanks again for the previous responses; I did get it working without freezing the guest. > If anyone on this thread were able to make and test a proper fix, I'm > sure we would all appreciate it. :-) > > At this point it would definitely not be a release blocker, but we > would obviously like to have it fixed. -Tony -- Antony Saba, antony.saba@mandiant.com