* Emulating in response of an int3 vm_event
@ 2015-11-30 23:32 Tamas K Lengyel
2015-12-01 0:01 ` Razvan Cojocaru
0 siblings, 1 reply; 11+ messages in thread
From: Tamas K Lengyel @ 2015-11-30 23:32 UTC (permalink / raw)
To: Razvan Cojocaru, Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3813 bytes --]
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!
Cheers,
Tamas
[-- Attachment #1.2: Type: text/html, Size: 4259 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-11-30 23:32 Emulating in response of an int3 vm_event Tamas K Lengyel
@ 2015-12-01 0:01 ` Razvan Cojocaru
2015-12-01 1:21 ` Tamas K Lengyel
0 siblings, 1 reply; 11+ messages in thread
From: Razvan Cojocaru @ 2015-12-01 0:01 UTC (permalink / raw)
To: Tamas K Lengyel, Xen-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-01 0:01 ` Razvan Cojocaru
@ 2015-12-01 1:21 ` Tamas K Lengyel
2015-12-01 10:40 ` Andrew Cooper
0 siblings, 1 reply; 11+ messages in thread
From: Tamas K Lengyel @ 2015-12-01 1:21 UTC (permalink / raw)
To: Razvan Cojocaru; +Cc: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5032 bytes --]
On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru <rcojocaru@bitdefender.com>
wrote:
> 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.
>
Yeap, thanks, will try to sprinkle some debug info in there. It's very easy
to reproduce as it crashes immediately on the first event.
>
> Is this code available somewhere, or is it maybe private code?
>
>
It's up on github at
https://github.com/tklengyel/xen/compare/int_emul?expand=1. I'm hoping to
send a patch for this in once I get it working.
Tamas
[-- Attachment #1.2: Type: text/html, Size: 6269 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-01 1:21 ` Tamas K Lengyel
@ 2015-12-01 10:40 ` Andrew Cooper
2015-12-01 10:51 ` Andrew Cooper
2015-12-02 18:21 ` Tamas K Lengyel
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Cooper @ 2015-12-01 10:40 UTC (permalink / raw)
To: Tamas K Lengyel, Razvan Cojocaru; +Cc: Xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --]
On 01/12/15 01:21, Tamas K Lengyel wrote:
>
>
> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>
> 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
>
This BUG() is the cause of the crash.
It is a bad parameter to VMREAD, by the looks of it.
~Andrew
[-- Attachment #1.2: Type: text/html, Size: 2672 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-01 10:40 ` Andrew Cooper
@ 2015-12-01 10:51 ` Andrew Cooper
2015-12-01 13:15 ` Jan Beulich
2015-12-02 18:21 ` Tamas K Lengyel
1 sibling, 1 reply; 11+ messages in thread
From: Andrew Cooper @ 2015-12-01 10:51 UTC (permalink / raw)
To: Tamas K Lengyel, Razvan Cojocaru; +Cc: Xen-devel, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 1413 bytes --]
On 01/12/15 10:40, Andrew Cooper wrote:
> On 01/12/15 01:21, Tamas K Lengyel wrote:
>>
>>
>> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
>> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>>
>> 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
>>
>
> This BUG() is the cause of the crash.
>
> It is a bad parameter to VMREAD, by the looks of it.
Jan: This is a good example of why unlikely regions should have
symbols. The stack trace from this bug is actively misleading because
the symbol information for %eip is wrong.
~Andrew
[-- Attachment #1.2: Type: text/html, Size: 3268 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-01 10:51 ` Andrew Cooper
@ 2015-12-01 13:15 ` Jan Beulich
0 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2015-12-01 13:15 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, Tamas K Lengyel, Razvan Cojocaru
>>> On 01.12.15 at 11:51, <andrew.cooper3@citrix.com> wrote:
> Jan: This is a good example of why unlikely regions should have
> symbols. The stack trace from this bug is actively misleading because
> the symbol information for %eip is wrong.
And I didn't object to there being a single label put at the beginning
of the "unlikely" portion of a single source file. All I objected to was
putting labels at every contribution a source file may make.
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-01 10:40 ` Andrew Cooper
2015-12-01 10:51 ` Andrew Cooper
@ 2015-12-02 18:21 ` Tamas K Lengyel
2015-12-02 18:34 ` Andrew Cooper
1 sibling, 1 reply; 11+ messages in thread
From: Tamas K Lengyel @ 2015-12-02 18:21 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, Razvan Cojocaru
[-- Attachment #1.1: Type: text/plain, Size: 5118 bytes --]
On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:
> On 01/12/15 01:21, Tamas K Lengyel wrote:
>
>
>
> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru <
> rcojocaru@bitdefender.com> wrote:
>
>> 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
>>
>
> This BUG() is the cause of the crash.
>
> It is a bad parameter to VMREAD, by the looks of it.
>
> ~Andrew
>
So this is quite confusing. The error seems to stem from
(XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c
in the line
hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current);
which is effectively a simple
__vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
My printk after this doesn't show up in the console so this must be where
the bug triggers.
(XEN) emulate.c:1828:d1v0 get interrupt shadow
(XEN) emulate.c:1830:d1v0 get interrupt shadow done
(XEN) emulate.c:1836:d1v0 get seg cs
(XEN) emulate.c:1838:d1v0 get seg ss
(XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
(XEN) emulate.c:1828:d0v0 get interrupt shadow
(XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
(XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
(XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0)
(XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx: 0000000000000000
(XEN) rdx: ffff8300ae308000 rsi: 000000000000000a rdi: ffff8300ae550000
(XEN) rbp: ffff8300ae30fb28 rsp: ffff8300ae30fb28 r8: ffff830430de0000
(XEN) r9: 0000000000000004 r10: 0000000000000004 r11: 0000000000000001
(XEN) r12: ffff8300ae308000 r13: ffff8300ae30ff18 r14: ffff8300ae0f8000
(XEN) r15: ffff82d08028a480 cr0: 0000000080050033 cr4: 00000000000426e0
(XEN) cr3: 000000043df79000 cr2: 00007f761d656000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) Xen stack trace from rsp=ffff8300ae30fb28:
(XEN) ffff8300ae30fb58 ffff82d0801d55ab 00007cff51cf0497 0000000000000006
(XEN) 00000000ffffffff 0000000000000002 ffff8300ae30fc98 ffff82d0801d5776
(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) 0000000000000000 0000000000000000 0000000000000048 ffff8300ae30fcd0
(XEN) ffff8300ae30fcd0 ffff830412da0c50 ffff8300ae30fcb8 ffff82d0801c02c1
(XEN) ffff8300ae30fcd0 ffff83040fbaf000 ffff8300ae30fe38 ffff82d08013a483
(XEN) 00007cff51cf0307 0000002500000001 0000000000000006 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) c214c48300000008 0000000064900010 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) [<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
(XEN) [<ffff82d0801d55ab>] hvm_emulate_prepare+0x50/0x10e
(XEN) [<ffff82d0801d5776>] hvm_mem_access_emulate_one+0x49/0xd3
(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
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
Why would that vmread fail there and why would the call trace tell me it's
in vmx_vmenter_helper?
Tamas
[-- Attachment #1.2: Type: text/html, Size: 7240 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-02 18:21 ` Tamas K Lengyel
@ 2015-12-02 18:34 ` Andrew Cooper
2015-12-02 18:38 ` Tamas K Lengyel
2015-12-03 11:09 ` Jan Beulich
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Cooper @ 2015-12-02 18:34 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Razvan Cojocaru
[-- Attachment #1.1: Type: text/plain, Size: 6187 bytes --]
On 02/12/15 18:21, Tamas K Lengyel wrote:
>
>
> On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
> On 01/12/15 01:21, Tamas K Lengyel wrote:
>>
>>
>> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
>> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>>
>> 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
>>
>
> This BUG() is the cause of the crash.
>
> It is a bad parameter to VMREAD, by the looks of it.
>
> ~Andrew
>
>
> So this is quite confusing. The error seems to stem from
> (XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c
>
> in the line
> hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current);
>
> which is effectively a simple
> __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
>
> My printk after this doesn't show up in the console so this must be
> where the bug triggers.
>
> (XEN) emulate.c:1828:d1v0 get interrupt shadow
> (XEN) emulate.c:1830:d1v0 get interrupt shadow done
> (XEN) emulate.c:1836:d1v0 get seg cs
> (XEN) emulate.c:1838:d1v0 get seg ss
> (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
> (XEN) emulate.c:1828:d0v0 get interrupt shadow
> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
> (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
> (XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0)
> (XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx:
> 0000000000000000
> (XEN) rdx: ffff8300ae308000 rsi: 000000000000000a rdi:
> ffff8300ae550000
> (XEN) rbp: ffff8300ae30fb28 rsp: ffff8300ae30fb28 r8:
> ffff830430de0000
> (XEN) r9: 0000000000000004 r10: 0000000000000004 r11:
> 0000000000000001
> (XEN) r12: ffff8300ae308000 r13: ffff8300ae30ff18 r14:
> ffff8300ae0f8000
> (XEN) r15: ffff82d08028a480 cr0: 0000000080050033 cr4:
> 00000000000426e0
> (XEN) cr3: 000000043df79000 cr2: 00007f761d656000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
> (XEN) Xen stack trace from rsp=ffff8300ae30fb28:
> (XEN) ffff8300ae30fb58 ffff82d0801d55ab 00007cff51cf0497
> 0000000000000006
> (XEN) 00000000ffffffff 0000000000000002 ffff8300ae30fc98
> ffff82d0801d5776
> (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) 0000000000000000 0000000000000000 0000000000000048
> ffff8300ae30fcd0
> (XEN) ffff8300ae30fcd0 ffff830412da0c50 ffff8300ae30fcb8
> ffff82d0801c02c1
> (XEN) ffff8300ae30fcd0 ffff83040fbaf000 ffff8300ae30fe38
> ffff82d08013a483
> (XEN) 00007cff51cf0307 0000002500000001 0000000000000006
> 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN) c214c48300000008 0000000064900010 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) [<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
> (XEN) [<ffff82d0801d55ab>] hvm_emulate_prepare+0x50/0x10e
> (XEN) [<ffff82d0801d5776>] hvm_mem_access_emulate_one+0x49/0xd3
> (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
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>
> Why would that vmread fail there and why would the call trace tell me
> it's in vmx_vmenter_helper?
The symbol information is incorrect because of the bugframe being inside
an UNLIKELY() block.
I have a patch to fix it,
http://www.gossamer-threads.com/lists/xen/devel/404482?do=post_view_threaded
but this has been rejected.
I don't see a way to make a global symbol for the current translation
units' unlikely section. I also don't believe it is a sensible approach
to take even if is a technical way to make it happen, as it still leaves
the stack trace not correctly identifying the source of the issue, so
the fix is in limbo.
~Andrew
[-- Attachment #1.2: Type: text/html, Size: 11447 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-02 18:34 ` Andrew Cooper
@ 2015-12-02 18:38 ` Tamas K Lengyel
2015-12-02 18:41 ` Andrew Cooper
2015-12-03 11:09 ` Jan Beulich
1 sibling, 1 reply; 11+ messages in thread
From: Tamas K Lengyel @ 2015-12-02 18:38 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, Razvan Cojocaru
[-- Attachment #1.1: Type: text/plain, Size: 6318 bytes --]
On Wed, Dec 2, 2015 at 1:34 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:
> On 02/12/15 18:21, Tamas K Lengyel wrote:
>
>
>
> On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
>
>> On 01/12/15 01:21, Tamas K Lengyel wrote:
>>
>>
>>
>> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru <
>> rcojocaru@bitdefender.com> wrote:
>>
>>> 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
>>>
>>
>> This BUG() is the cause of the crash.
>>
>> It is a bad parameter to VMREAD, by the looks of it.
>>
>> ~Andrew
>>
>
> So this is quite confusing. The error seems to stem from
> (XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c
>
> in the line
> hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current);
>
> which is effectively a simple
> __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
>
> My printk after this doesn't show up in the console so this must be where
> the bug triggers.
>
> (XEN) emulate.c:1828:d1v0 get interrupt shadow
> (XEN) emulate.c:1830:d1v0 get interrupt shadow done
> (XEN) emulate.c:1836:d1v0 get seg cs
> (XEN) emulate.c:1838:d1v0 get seg ss
> (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
> (XEN) emulate.c:1828:d0v0 get interrupt shadow
> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
> (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
> (XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0)
> (XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx: 0000000000000000
> (XEN) rdx: ffff8300ae308000 rsi: 000000000000000a rdi: ffff8300ae550000
> (XEN) rbp: ffff8300ae30fb28 rsp: ffff8300ae30fb28 r8: ffff830430de0000
> (XEN) r9: 0000000000000004 r10: 0000000000000004 r11: 0000000000000001
> (XEN) r12: ffff8300ae308000 r13: ffff8300ae30ff18 r14: ffff8300ae0f8000
> (XEN) r15: ffff82d08028a480 cr0: 0000000080050033 cr4: 00000000000426e0
> (XEN) cr3: 000000043df79000 cr2: 00007f761d656000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
> (XEN) Xen stack trace from rsp=ffff8300ae30fb28:
> (XEN) ffff8300ae30fb58 ffff82d0801d55ab 00007cff51cf0497
> 0000000000000006
> (XEN) 00000000ffffffff 0000000000000002 ffff8300ae30fc98
> ffff82d0801d5776
> (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) 0000000000000000 0000000000000000 0000000000000048
> ffff8300ae30fcd0
> (XEN) ffff8300ae30fcd0 ffff830412da0c50 ffff8300ae30fcb8
> ffff82d0801c02c1
> (XEN) ffff8300ae30fcd0 ffff83040fbaf000 ffff8300ae30fe38
> ffff82d08013a483
> (XEN) 00007cff51cf0307 0000002500000001 0000000000000006
> 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN) c214c48300000008 0000000064900010 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) [<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
> (XEN) [<ffff82d0801d55ab>] hvm_emulate_prepare+0x50/0x10e
> (XEN) [<ffff82d0801d5776>] hvm_mem_access_emulate_one+0x49/0xd3
> (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
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>
> Why would that vmread fail there and why would the call trace tell me it's
> in vmx_vmenter_helper?
>
>
> The symbol information is incorrect because of the bugframe being inside
> an UNLIKELY() block.
>
> I have a patch to fix it,
> http://www.gossamer-threads.com/lists/xen/devel/404482?do=post_view_threaded
> but this has been rejected.
>
> I don't see a way to make a global symbol for the current translation
> units' unlikely section. I also don't believe it is a sensible approach to
> take even if is a technical way to make it happen, as it still leaves the
> stack trace not correctly identifying the source of the issue, so the fix
> is in limbo.
>
> ~Andrew
>
I see, thanks for the explanation.
In the meanwhile I noticed that the vmread fails as it happens in the
context of d0v0 instead of d1v1. Unfortunately the entire emulation code is
pretty much hard-coded to use "current" everywhere so I'm not sure how I
could make use of it here.
Tamas
[-- Attachment #1.2: Type: text/html, Size: 11752 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-02 18:38 ` Tamas K Lengyel
@ 2015-12-02 18:41 ` Andrew Cooper
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Cooper @ 2015-12-02 18:41 UTC (permalink / raw)
To: Tamas K Lengyel; +Cc: Xen-devel, Razvan Cojocaru
[-- Attachment #1.1: Type: text/plain, Size: 7502 bytes --]
On 02/12/15 18:38, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 2, 2015 at 1:34 PM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
> On 02/12/15 18:21, Tamas K Lengyel wrote:
>>
>>
>> On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper
>> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>>
>> On 01/12/15 01:21, Tamas K Lengyel wrote:
>>>
>>>
>>> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru
>>> <rcojocaru@bitdefender.com
>>> <mailto:rcojocaru@bitdefender.com>> wrote:
>>>
>>> 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
>>>
>>
>> This BUG() is the cause of the crash.
>>
>> It is a bad parameter to VMREAD, by the looks of it.
>>
>> ~Andrew
>>
>>
>> So this is quite confusing. The error seems to stem from
>> (XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c
>>
>> in the line
>> hvmemul_ctxt->intr_shadow =
>> hvm_funcs.get_interrupt_shadow(current);
>>
>> which is effectively a simple
>> __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow);
>>
>> My printk after this doesn't show up in the console so this must
>> be where the bug triggers.
>>
>> (XEN) emulate.c:1828:d1v0 get interrupt shadow
>> (XEN) emulate.c:1830:d1v0 get interrupt shadow done
>> (XEN) emulate.c:1836:d1v0 get seg cs
>> (XEN) emulate.c:1838:d1v0 get seg ss
>> (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37
>> (XEN) emulate.c:1828:d0v0 get interrupt shadow
>> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>> (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]----
>> (XEN) CPU: 0
>> (XEN) RIP: e008:[<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
>> (XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0)
>> (XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx:
>> 0000000000000000
>> (XEN) rdx: ffff8300ae308000 rsi: 000000000000000a rdi:
>> ffff8300ae550000
>> (XEN) rbp: ffff8300ae30fb28 rsp: ffff8300ae30fb28 r8:
>> ffff830430de0000
>> (XEN) r9: 0000000000000004 r10: 0000000000000004 r11:
>> 0000000000000001
>> (XEN) r12: ffff8300ae308000 r13: ffff8300ae30ff18 r14:
>> ffff8300ae0f8000
>> (XEN) r15: ffff82d08028a480 cr0: 0000000080050033 cr4:
>> 00000000000426e0
>> (XEN) cr3: 000000043df79000 cr2: 00007f761d656000
>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
>> (XEN) Xen stack trace from rsp=ffff8300ae30fb28:
>> (XEN) ffff8300ae30fb58 ffff82d0801d55ab 00007cff51cf0497
>> 0000000000000006
>> (XEN) 00000000ffffffff 0000000000000002 ffff8300ae30fc98
>> ffff82d0801d5776
>> (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) 0000000000000000 0000000000000000 0000000000000048
>> ffff8300ae30fcd0
>> (XEN) ffff8300ae30fcd0 ffff830412da0c50 ffff8300ae30fcb8
>> ffff82d0801c02c1
>> (XEN) ffff8300ae30fcd0 ffff83040fbaf000 ffff8300ae30fe38
>> ffff82d08013a483
>> (XEN) 00007cff51cf0307 0000002500000001 0000000000000006
>> 0000000000000000
>> (XEN) 0000000000000000 0000000000000000 0000000000000000
>> 0000000000000000
>> (XEN) c214c48300000008 0000000064900010 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) [<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd
>> (XEN) [<ffff82d0801d55ab>] hvm_emulate_prepare+0x50/0x10e
>> (XEN) [<ffff82d0801d5776>] hvm_mem_access_emulate_one+0x49/0xd3
>> (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
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372
>>
>> Why would that vmread fail there and why would the call trace
>> tell me it's in vmx_vmenter_helper?
>
> The symbol information is incorrect because of the bugframe being
> inside an UNLIKELY() block.
>
> I have a patch to fix it,
> http://www.gossamer-threads.com/lists/xen/devel/404482?do=post_view_threaded
> but this has been rejected.
>
> I don't see a way to make a global symbol for the current
> translation units' unlikely section. I also don't believe it is a
> sensible approach to take even if is a technical way to make it
> happen, as it still leaves the stack trace not correctly
> identifying the source of the issue, so the fix is in limbo.
>
> ~Andrew
>
>
> I see, thanks for the explanation.
>
> In the meanwhile I noticed that the vmread fails as it happens in the
> context of d0v0 instead of d1v1. Unfortunately the entire emulation
> code is pretty much hard-coded to use "current" everywhere so I'm not
> sure how I could make use of it here.
You will need to vmx_vmcs_{enter,exit}() to get the correct vmcs in context.
~Andrew
[-- Attachment #1.2: Type: text/html, Size: 17753 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Emulating in response of an int3 vm_event
2015-12-02 18:34 ` Andrew Cooper
2015-12-02 18:38 ` Tamas K Lengyel
@ 2015-12-03 11:09 ` Jan Beulich
1 sibling, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2015-12-03 11:09 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, Tamas K Lengyel, Razvan Cojocaru
>>> On 02.12.15 at 19:34, <andrew.cooper3@citrix.com> wrote:
> On 02/12/15 18:21, Tamas K Lengyel wrote:
>> Why would that vmread fail there and why would the call trace tell me
>> it's in vmx_vmenter_helper?
>
> The symbol information is incorrect because of the bugframe being inside
> an UNLIKELY() block.
>
> I have a patch to fix it,
> http://www.gossamer-threads.com/lists/xen/devel/404482?do=post_view_threaded
> but this has been rejected.
>
> I don't see a way to make a global symbol for the current translation
> units' unlikely section. I also don't believe it is a sensible approach
> to take even if is a technical way to make it happen, as it still leaves
> the stack trace not correctly identifying the source of the issue, so
> the fix is in limbo.
I still don't see how that patch would help: You'd have a series of
machine generated unlikely.vmread.<n> labels in them, which
would still require you to look things up in disassembly. No different
to what I'm suggesting, only causing symbol table bloat.
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-12-03 11:09 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-30 23:32 Emulating in response of an int3 vm_event Tamas K Lengyel
2015-12-01 0:01 ` Razvan Cojocaru
2015-12-01 1:21 ` Tamas K Lengyel
2015-12-01 10:40 ` Andrew Cooper
2015-12-01 10:51 ` Andrew Cooper
2015-12-01 13:15 ` Jan Beulich
2015-12-02 18:21 ` Tamas K Lengyel
2015-12-02 18:34 ` Andrew Cooper
2015-12-02 18:38 ` Tamas K Lengyel
2015-12-02 18:41 ` Andrew Cooper
2015-12-03 11:09 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.