[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Emulating in response of an int3 vm_event


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 1 Dec 2015 02:01:13 +0200
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 01 Dec 2015 00:01:44 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=qHv4v0BY2ecfHOBGe3zgvk98cLJCptisQ14wnkwRHCFLy4DhrAWVlOMElOmqTU5rtMdqYjMXalHowU/c0r7bhZGjwsNwslKRvr8wLox7tSsALPW1Vgcat00IV4uyJhKgQixktUfwqcDCBSEiiAF/JJRMrLgHp4JCFns70Wo5eCCAf0HP+nqGpG+QBbmFCyLCIfiAQ1cLlHnMcZeqWrxZGCmm7AgtiSC07QZH3JVqeqkM2d70n2t1dlneJ8SWZFgzTVRq56LgMT4Tb5EbmdJxFcPskPPbNSc+/h4Z1l5vBzufLlYK4RJmNq7IBlRrZlhI+UZvaEEwqSyO6DJ0aDQCzA==; h=Received:Received:Received:Received:Received:Subject:To:References:From:X-Enigmail-Draft-Status:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 12/01/2015 01:32 AM, Tamas K Lengyel wrote:
> Hi all,
> I'm trying to extend the current vm_event system to be able to emulate
> over an in-guest breakpoint using the VM_EVENT_FLAG_SET_EMUL_READ_DATA
> feature. The idea is to have the vm_event listener send back the
> contents of the memory that was overwritten by the breakpoint
> instruction, have Xen emulate one instruction, and resume execution
> normally afterwards. This would eliminate the need of removing the
> breakpoint, singlestepping, and placing the breakpoint back again.
> 
> Unfortunately I encounter this crash when I call
> hvm_mem_access_emulate_one in the event response handler:
> 
> (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
> (XEN) ----[ Xen-4.7-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d080202e90>] vmx_vmenter_helper+0x16d/0x30d
> (XEN) RFLAGS: 0000000000010203   CONTEXT: hypervisor (d0v0)
> (XEN) rax: 0000000000004824   rbx: ffff8300ae30fb68   rcx: 0000000000000000
> (XEN) rdx: 00000000ffffffff   rsi: ffff8300ae30ff18   rdi: ffff8300ae550000
> (XEN) rbp: ffff8300ae30fb38   rsp: ffff8300ae30fb38   r8:  ffff830430de0000
> (XEN) r9:  0000000000000004   r10: 0000000000000004   r11: 0000000000000002
> (XEN) r12: ffff8300ae30ff18   r13: 0000000000000002   r14: ffff8300ae35f000
> (XEN) r15: ffff82d08028a448   cr0: 0000000080050033   cr4: 00000000000426e0
> (XEN) cr3: 000000040f750000   cr2: 00007f7550df2000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff8300ae30fb38:
> (XEN)    ffff8300ae30fb58 ffff82d0801d557e 0000000000000006 00000000ffffffff
> (XEN)    ffff8300ae30fc98 ffff82d0801d56d4 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000048 ffff8300ae30fcd0 ffff8300ae30fcd0 ffff830135da1810
> (XEN)    ffff8300ae30fcb8 ffff82d0801c02c1 ffff8300ae30fcd0 ffff830135da3000
> (XEN)    ffff8300ae30fe38 ffff82d08013a483 000000000040f750 0000002500000001
> (XEN)    0000000000000006 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 c214c48300000008 0000000064900010
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82d080202e90>] vmx_vmenter_helper+0x16d/0x30d
> (XEN)    [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c
> (XEN)    [<ffff82d0801d56d4>] hvm_mem_access_emulate_one+0x49/0xd5
> (XEN)    [<ffff82d0801c02c1>] vm_event_interrupt_emulate_check+0x5c/0x63
> (XEN)    [<ffff82d08013a483>] vm_event_resume+0xa1/0x131
> (XEN)    [<ffff82d08013a914>] vm_event.c#monitor_notification+0x25/0x28
> (XEN)    [<ffff82d080108554>] evtchn_send+0x126/0x17e
> (XEN)    [<ffff82d080109a74>] do_event_channel_op+0xe66/0x14be
> (XEN)    [<ffff82d08024d992>] lstar_enter+0xe2/0x13c
> 
> From this trace I'm not actually sure what is causing the crash. If
> someone has an idea, help would be much appreciated!

I'm not sure what's causing the crash, but vmx_vmenter_helper() is a
fairly short function so I'd suggest sprinkling a few printk()s and see
which one is the first one to not show up before the stack trace, until
you can pinpoint the exact place causing the crash.

Either that, or try to disassemble the hypervisor binary and see what's
at vmx_vmenter_helper+0x16d/0x30d, but I'd use the printk() method if
this is easily reproduced.

Is this code available somewhere, or is it maybe private code?


Cheers,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.