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

Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain



Stack corruption/overflow, possibly?

 K.

On 7/8/07 17:06, "Brady Chen" <chenchp@xxxxxxxxx> wrote:

> Yes, the printfs are the only changes. once I remove these prints, the
> trap comes back, with the same EIP (D0800)
> 
> I tried to keep the first two printfs, the trap comes with different
> EIP(D19FD)
> static unsigned
> address(struct regs *regs, unsigned seg, unsigned off)
> {
>         uint64_t gdt_phys_base;
>         unsigned long long entry;
>         unsigned seg_base, seg_limit;
>         unsigned entry_low, entry_high;
> 
>         printf("f 1\n");
>         if (seg == 0) {
>                 if (mode == VM86_REAL || mode == VM86_REAL_TO_PROTECTED)
>                         return off;
>                 else
>                         panic("segment is zero, but not in real mode!\n");
>         }
> 
>         printf("f 2\n");
> 
> xen dmesg output:
> (XEN) HVM3: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
> (XEN) HVM3: f 1
> (XEN) HVM3: f 2
> (XEN) HVM3: 0x0000D71F: 0xD00:0x071F (0) external interrupt 8
> (XEN) HVM3: f 1
> (XEN) HVM3: f 1
> (XEN) HVM3: f 1
> (XEN) HVM3: Trap (0x6) while in real mode
> (XEN) HVM3: eax        CFAE ecx           0 edx           0 ebx       D75B4
> (XEN) HVM3: esp       D7564 ebp       D75A0 esi         71F edi           8
> (XEN) HVM3: trapno        6 errno         0
> (XEN) HVM3: eip       D19FD cs           10 eflags    13046
> (XEN) HVM3: uesp       CFAE uss           0
> (XEN) HVM3: ves       D4C44 vds           8 vfs          83 vgs         71F
> (XEN) HVM3: cr0       50032 cr2           0 cr3           0 cr4         651
> (XEN) HVM3:
> (XEN) HVM3: Halt called from %eip 0xD037C
> 
> 
> and the objdump shows that:
> 000d1970 <interrupt>:
>    d1970:       55                      push   %ebp
>    d1971:       89 e5                   mov    %esp,%ebp
>    d1973:       57                      push   %edi
>    d1974:       89 d7                   mov    %edx,%edi
>    d1976:       56                      push   %esi
>   ....
>    d19f8:       66 89 30                mov    %si,(%eax)
>    d19fb:       31 d2                   xor    %edx,%edx
>    d19fd:       8d 34 bd 00 00 00 00    lea    0x0(,%edi,4),%esi
>    d1a04:       81 63 30 ff fd ff ff    andl   $0xfffffdff,0x30(%ebx)
>    d1a0b:       89 d8                   mov    %ebx,%eax
>    d1a0d:       89 34 24                mov    %esi,(%esp)
> 
> 
> On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>> Very weird. The emulations now aren't at the same address as before either
>> (0xd4c3 rather than 0xd71b). Is the *only* difference that you added these
>> printf()s -- is it at all possible that the guest is executing down a
>> different path here for other reasons? If it's really down to the printf()s
>> then I guess you'll have to shuffle/remove printf()s to get the old
>> behaviour back.
>> 
>>  -- Keir
>> 
>> On 7/8/07 12:35, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>> 
>>> it's strange:
>>> if i add these prints, i get " Unknown opcode", not "trap".
>>> ===added printf
>>> [root@localhost firmware]# hg diff -p  vmxassist/vm86.c
>>> diff -r 6f18f5bdeea3 tools/firmware/vmxassist/vm86.c
>>> --- a/tools/firmware/vmxassist/vm86.c   Mon Aug 06 15:33:42 2007 +0100
>>> +++ b/tools/firmware/vmxassist/vm86.c   Tue Aug 07 19:33:55 2007 +0800
>>> @@ -40,7 +40,7 @@ static struct regs saved_rm_regs;
>>>  static struct regs saved_rm_regs;
>>> 
>>>  #ifdef DEBUG
>>> -int traceset = 0;
>>> +int traceset = ~0;
>>> 
>>>  char *states[] = {
>>>         "<VM86_REAL>",
>>> @@ -128,6 +128,7 @@ address(struct regs *regs, unsigned seg,
>>>         unsigned seg_base, seg_limit;
>>>         unsigned entry_low, entry_high;
>>> 
>>> +       printf("f 1\n");
>>>         if (seg == 0) {
>>>                 if (mode == VM86_REAL || mode == VM86_REAL_TO_PROTECTED)
>>>                         return off;
>>> @@ -135,12 +136,16 @@ address(struct regs *regs, unsigned seg,
>>>                         panic("segment is zero, but not in real mode!\n");
>>>         }
>>> 
>>> +       printf("f 2\n");
>>>         if (mode == VM86_REAL || seg > oldctx.gdtr_limit ||
>>>                 (mode == VM86_REAL_TO_PROTECTED && regs->cs == seg))
>>>                 return ((seg & 0xFFFF) << 4) + off;
>>> 
>>> +       printf("f 3\n");
>>>         gdt_phys_base = guest_linear_to_phys(oldctx.gdtr_base);
>>> +       printf("f 4\n");
>>>         if (gdt_phys_base != (uint32_t)gdt_phys_base) {
>>> +               printf("f 5\n");
>>>                 printf("gdt base address above 4G\n");
>>>                 cpuid_addr_value(gdt_phys_base + 8 * (seg >> 3), &entry);
>>>         } else
>>> @@ -152,14 +157,17 @@ address(struct regs *regs, unsigned seg,
>>>         seg_base  = (entry_high & 0xFF000000) | ((entry >> 16) & 0xFFFFFF);
>>>         seg_limit = (entry_high & 0xF0000) | (entry_low & 0xFFFF);
>>> 
>>> +       printf("f 6\n");
>>>         if (entry_high & 0x8000 &&
>>>                 ((entry_high & 0x800000 && off >> 12 <= seg_limit) ||
>>>                 (!(entry_high & 0x800000) && off <= seg_limit)))
>>>                 return seg_base + off;
>>> +       printf("f 7\n");
>>> 
>>>         panic("should never reach here in function address():\n\t"
>>>                   "entry=0x%08x%08x, mode=%d, seg=0x%08x, offset=0x%08x\n",
>>>                   entry_high, entry_low, mode, seg, off);
>>> +       printf("f 8\n");
>>> 
>>>         return 0;
>>>  }
>>> @@ -286,6 +294,7 @@ fetch8(struct regs *regs)
>>>         unsigned addr = address(regs, regs->cs, MASK16(regs->eip));
>>> 
>>>         regs->eip++;
>>> +       printf("f 9\n");
>>>         return read8(addr);
>>>  }
>>> 
>>> ===output when add many printf
>>> (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) addr32addr32f 1
>>> (XEN) HVM12: f 2
>>> (XEN) HVM12: f 9
>>> (XEN) HVM12: f 1
>>> (XEN) HVM12: f 2
>>> (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) data32data32f 1
>>> (XEN) HVM12: f 2
>>> (XEN) HVM12: f 9
>>> (XEN) HVM12: f 1
>>> (XEN) HVM12: f 2
>>> (XEN) HVM12: 0x0000D4C3: 0xD00:0x04C3 (0) opc 0x83opc 0xD7704f 1
>>> (XEN) HVM12: f 2
>>> (XEN) HVM12: Unknown opcode at 0D00:04C3=0xD4C3
>>> (XEN) HVM12: Halt called from %eip 0xD3B4A
>>> 
>>> On 8/7/07, Brady Chen <chenchp@xxxxxxxxx> wrote:
>>>> Hi, yes, it's crashed in fetch8. it's very slow after I add this print
>>>> info.
>>>> the main function of fetch8 seems to be address(). seems crashed in
>>>> address().
>>>> 
>>>> (XEN) HVM7: after write16 of movw
>>>> (XEN) HVM7: top of opcode
>>>> (XEN) HVM7: Before fetch8
>>>> (XEN) HVM7: eax        7E80 ecx        2D1B edx           0 ebx        404E
>>>> (XEN) HVM7: esp       D76F4 ebp        1FF0 esi         7BE edi       C37FE
>>>> (XEN) HVM7: trapno        D errno         0
>>>> (XEN) HVM7: eip         71F cs          D00 eflags    33206
>>>> (XEN) HVM7: uesp       CFB4 uss           0
>>>> (XEN) HVM7: ves         D00 vds         D00 vfs           0 vgs           0
>>>> (XEN) HVM7: cr0       50032 cr2           0 cr3           0 cr4         651
>>>> (XEN) HVM7:
>>>> (XEN) HVM7: Trap (0x6) while in real mode
>>>> (XEN) HVM7: eax         D00 ecx           0 edx         71F ebx          89
>>>> (XEN) HVM7: esp       D75E4 ebp       D7630 esi       D7620 edi         D00
>>>> (XEN) HVM7: trapno        6 errno         0
>>>> (XEN) HVM7: eip       D0800 cs           10 eflags    13046
>>>> (XEN) HVM7: uesp        71F uss       D76D4
>>>> (XEN) HVM7: ves       D7610 vds       D3AB9 vfs       D762C vgs       D7644
>>>> (XEN) HVM7: cr0       50032 cr2           0 cr3           0 cr4         651
>>>> (XEN) HVM7:
>>>> (XEN) HVM7: 0xd0800 is 0xFFFF
>>>> (XEN) HVM7: 0xd0804 is 0x7D8B
>>>> (XEN) HVM7: Halt called from %eip 0xD037C
>>>> 
>>>> 
>>>> On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>>>>> How about trying:
>>>>>  printf("Before fetch8\n");
>>>>>  dump_regs(regs);
>>>>>  opc = fetch8(regs);
>>>>>  printf("After fetch8\n");
>>>>>  switch (opc) { ...
>>>>> 
>>>>> This will let you see what eip is being fetched from, and also confirm
>>>>> that
>>>>> the crash happens within fetch8().
>>>>> 
>>>>> You could also try adding more printf()s inside fetch8() and address() to
>>>>> find out which specific bit of fetch8() is crashing (if that indeed the
>>>>> function that is crashing).
>>>>> 
>>>>>  -- Keir
>>>>> 
>>>>> On 7/8/07 11:30, "Brady Chen" <chenchp@xxxxxxxxx> wrote:
>>>>> 
>>>>>> Hi, Keir,
>>>>>> I made the change as you said:
>>>>>> change diff is:
>>>>>> [root@localhost firmware]# hg diff vmxassist/vm86.c
>>>>>> diff -r 6f18f5bdeea3 tools/firmware/vmxassist/vm86.c
>>>>>> --- a/tools/firmware/vmxassist/vm86.c   Mon Aug 06 15:33:42 2007 +0100
>>>>>> +++ b/tools/firmware/vmxassist/vm86.c   Tue Aug 07 18:26:12 2007 +0800
>>>>>> @@ -40,7 +40,7 @@ static struct regs saved_rm_regs;
>>>>>>  static struct regs saved_rm_regs;
>>>>>> 
>>>>>>  #ifdef DEBUG
>>>>>> -int traceset = 0;
>>>>>> +int traceset = ~0;
>>>>>> 
>>>>>>  char *states[] = {
>>>>>>         "<VM86_REAL>",
>>>>>> @@ -620,6 +620,7 @@ movr(struct regs *regs, unsigned prefix,
>>>>>>                         TRACE((regs, regs->eip - eip,
>>>>>>                                 "movw %%%s, *0x%x", rnames[r], addr));
>>>>>>                         write16(addr, MASK16(val));
>>>>>> +                       printf("after write16 of movw\n");
>>>>>>                 }
>>>>>>                 return 1;
>>>>>> 
>>>>>> @@ -1305,6 +1306,7 @@ opcode(struct regs *regs)
>>>>>>         unsigned eip = regs->eip;
>>>>>>         unsigned opc, modrm, disp;
>>>>>>         unsigned prefix = 0;
>>>>>> +       printf("top of opcode\n");
>>>>>> 
>>>>>>         if (mode == VM86_PROTECTED_TO_REAL &&
>>>>>>                 oldctx.cs_arbytes.fields.default_ops_size) {
>>>>>> @@ -1712,6 +1714,8 @@ trap(int trapno, int errno, struct regs
>>>>>>                 if (trapno == 14)
>>>>>>                         printf("Page fault address 0x%x\n", get_cr2());
>>>>>>                 dump_regs(regs);
>>>>>> +               printf("0xd0800 is 0x%0x\n", *((unsigned
>>>>>> short*)0xd0800));
>>>>>> +               printf("0xd0804 is 0x%0x\n", *((unsigned
>>>>>> short*)0xd0804));
>>>>>>                 halt();
>>>>>>         }
>>>>>>  }
>>>>>> 
>>>>>> 
>>>>>> here is the output:
>>>>>> (XEN) HVM6: top of opcode
>>>>>> (XEN) HVM6: 0x0000D71F: 0xD00:0x071F (0) data32
>>>>>> (XEN) HVM6: 0x0000D71F: 0xD00:0x071F (0) opc 0x83
>>>>>> (XEN) HVM6: top of opcode
>>>>>> (XEN) HVM6: 0x0000D71B: 0xD00:0x071B (0) %es:
>>>>>> (XEN) HVM6: 0x0000D71B: 0xD00:0x071B (0) addr32
>>>>>> (XEN) HVM6: 0x0000D71D: 0xD00:0x071D (0) movw %ax, *0xD07FE
>>>>>> (XEN) HVM6: after write16 of movw
>>>>>> (XEN) HVM6: top of opcode
>>>>>> (XEN) HVM6: Trap (0x6) while in real mode
>>>>>> (XEN) HVM6: eax         D00 ecx           0 edx         71F ebx
>>>>>> 71E
>>>>>> (XEN) HVM6: esp       D7554 ebp       D75A0 esi       D7590 edi
>>>>>> D00
>>>>>> (XEN) HVM6: trapno        6 errno         0
>>>>>> (XEN) HVM6: eip       D0800 cs           10 eflags    13046
>>>>>> (XEN) HVM6: uesp      D4C29 uss           2
>>>>>> (XEN) HVM6: ves       D4C18 vds       D4D9C vfs       D07FE vgs
>>>>>> D75B4
>>>>>> (XEN) HVM6: cr0       50032 cr2           0 cr3           0 cr4
>>>>>> 651
>>>>>> (XEN) HVM6:
>>>>>> (XEN) HVM6: 0xd0800 is 0xFFFF
>>>>>> (XEN) HVM6: 0xd0804 is 0x7D8B
>>>>>> (XEN) HVM6: Halt called from %eip 0xD037C
>>>>>> 
>>>>>> objdump:
>>>>>>    d07ef:       e9 2f ff ff ff          jmp    d0723 <address+0x23>
>>>>>>    d07f4:       8b 55 08                mov    0x8(%ebp),%edx
>>>>>>    d07f7:       89 f8                   mov    %edi,%eax
>>>>>>    d07f9:       8b 5d f4                mov    0xfffffff4(%ebp),%ebx
>>>>>>    d07fc:       8b 75 f8                mov    0xfffffff8(%ebp),%esi
>>>>>>    d07ff:       25 ff ff 00 00          and    $0xffff,%eax
>>>>>>    d0804:       8b 7d fc                mov    0xfffffffc(%ebp),%edi
>>>>>>    d0807:       89 ec                   mov    %ebp,%esp
>>>>>>    d0809:       c1 e0 04                shl    $0x4,%eax
>>>>>>    d080c:       01 d0                   add    %edx,%eax
>>>>>>    d080e:       5d                      pop    %ebp
>>>>>> 
>>>>>> seems the memory is correct, it's crashed in opcode()
>>>>>> and i think it's fetch8(regs) which crash the system. I tried
>>>>>> fetch8(regs) in trap(), but it cause more traps, and let the hvm guest
>>>>>> be reset.
>>>>>> 
>>>>>> On 8/7/07, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
>>>>>>> On 7/8/07 10:29, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
>>>>>>> 
>>>>>>>> What would be useful is to try to add tracing to see how far vmxassist
>>>>>>>> gets
>>>>>>>> after its last line of tracing before the trap occurs. That last line
>>>>>>>> is
>>>>>>>> currently from vm86.c, line 620. You might try adding extra printf()
>>>>>>>> statements imemdiately after the write16() on line 622, and also at the
>>>>>>>> top
>>>>>>>> of the opcode() function. We need to find out at what point vmxassist
>>>>>>>> is
>>>>>>>> jumping to this bogus address d0800.
>>>>>>> 
>>>>>>> Oh, another possibility is that vmxassist has been corrupted in memory.
>>>>>>> This
>>>>>>> is particularly likely because, according to the objdump, the
>>>>>>> 'instruction'
>>>>>>> that starts at d0800 is actually valid (it'd be an ADD of some sort).
>>>>>>> 
>>>>>>> So, within trap() you might want to read say 16 bytes starting at
>>>>>>> 0xd0800
>>>>>>> and printf() them. So we can see if they match what objdump says should
>>>>>>> be
>>>>>>> there.
>>>>>>> 
>>>>>>>  -- Keir
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>> http://lists.xensource.com/xen-devel
>>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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