Haven''t worked out exactly what''s causing the bug, but in
testing the
pv_ops tree against current Xen (11736:f7d65fb7299b) I can reliably
crash Xen with the following trace, caused by:
arch/x86/traps.c::handle_gdt_ldt_mapping_fault()
...
/* Should never fault in another vcpu''s area. */
BUG_ON(vcpu_area != current->vcpu_id);
(XEN) BUG at traps.c:715
(XEN) ----Ä Xen-3.0-unstable x86_32 debug=y Not tainted Ü----
(XEN) CPU: 1
(XEN) EIP: e008:Ä<ff11c1e8>Ü __bug+0x25/0x29
(XEN) EFLAGS: 00210296 CONTEXT: hypervisor
(XEN) eax: 00000000 ebx: ffbdc080 ecx: 0000000a edx: ff1c6d53
(XEN) esi: ff1fbef8 edi: fe964194 ebp: ff1fbebc esp: ff1fbea4
(XEN) cr0: 8005003b cr4: 000026d0 cr3: 43d5b000 cr2: fe964194
(XEN) ds: e010 es: e010 fs: 0000 gs: 00d8 ss: e010 cs: e008
(XEN) Xen stack trace from esp=ff1fbea4:
(XEN) ff17d1bc ff17eb6f 000002cb 00000001 ffbdc080 ffbdc080 ff1fbeec ff137c66
(XEN) ff17eb6f 000002cb 00043d5b ff1198c6 ff1167cd ffbca080 44e07067 ffbca080
(XEN) 00a59065 c2fcfea4 00e040f3 ff16690a ff1fbef8 00a59065 ff1fbfb4 ffbdc080
(XEN) 00a59065 c2fcfea4 ff1fbf8c 00000000 000e0000 ff12e006 0000e008 00210246
(XEN) ff1fbf74 c2fcfe98 0000000c c011548a 00000061 00210202 c2fcfeac 00000069
(XEN) 00000000 0000007b ffbca080 ffbdc080 00000000 c2fcfe98 fede8dac 0076b063
(XEN) 000462c0 0003a253 00000000 00000000 00000006 00a59065 c2fcfeac ffbca080
(XEN) 0000001a ff1fbfac 00e04037 ff1665fd c2fcfe98 00000001 00000000 00007ff0
(XEN) deadbeef deadbeef c0102347 0000001a c2fcfe98 00000001 00000000 00007ff0
(XEN) c1014b20 c2fcfeac 0000001a 000e0003 c0102347 00000061 00200292 c2fcfe94
(XEN) 00000069 0000007b 0000007b 00000000 000000d8 00000001 ffbca080
(XEN) Xen call trace:
(XEN) Ä<ff11c1e8>Ü __bug+0x25/0x29
(XEN) Ä<ff137c66>Ü do_page_fault+0x25e/0x6ea
(XEN) Ä<ff16690a>Ü handle_exception+0x6a/0x9a
(XEN) Ä<ff12e006>Ü do_mmuext_op+0x2a8/0xd49
(XEN) Ä<ff1665fd>Ü hypercall+0x9d/0xbd
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) CPU1 FATAL TRAP: vector = 6 (invalid opcode)
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 12/10/06 07:26, "Chris Wright" <chrisw@sous-sol.org> wrote:> Haven''t worked out exactly what''s causing the bug, but in testing the > pv_ops tree against current Xen (11736:f7d65fb7299b) I can reliably > crash Xen with the following trace, caused by: > > arch/x86/traps.c::handle_gdt_ldt_mapping_fault() > ... > /* Should never fault in another vcpu''s area. */ > BUG_ON(vcpu_area != current->vcpu_id);The shadow-refcount code is quite fresh. We should confirm this isn''t exploitable by ordinary PV guests though. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Keir Fraser (Keir.Fraser@cl.cam.ac.uk) wrote:> On 12/10/06 07:26, "Chris Wright" <chrisw@sous-sol.org> wrote: > > > Haven''t worked out exactly what''s causing the bug, but in testing the > > pv_ops tree against current Xen (11736:f7d65fb7299b) I can reliably > > crash Xen with the following trace, caused by: > > > > arch/x86/traps.c::handle_gdt_ldt_mapping_fault() > > ... > > /* Should never fault in another vcpu''s area. */ > > BUG_ON(vcpu_area != current->vcpu_id); > > The shadow-refcount code is quite fresh. We should confirm this isn''t > exploitable by ordinary PV guests though.Indeed, I''ll dig at this a little more. thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel