Xen devel - Nov 2006 - RE: [Patch] Fix for x86_64 boot failures due to badsegment setup for protected mode.

This patch caused one problem.

If the guest change the DS/SS etc between it set cr0.PE and the jump
instruction.
Considering following code:
   mov eax, cr0
   or eax, 0x11
  mov cr0, eax		---> here enable PE, and old_ctx.ds is cleard
   mov ax, 0x0020
   mov ds, ax		-> changes the DS here
  jmp pword ptr [edi + 0x60]
  mov ax, word ptr [bx + 0x00a8]

The vmxassit clear the oldctx.ds_sel when guest enable PE, and when guest
executed the mov ds, ax, the content on oldctx is not updated. Later when the
last instruction, the ds is infact 0x0, not the 0x20 as guest hoped.

This issue is in fact not caused entirely by this change, since we should
emulate all instructions between the set cr0.PE and the jump instruction. But
because the "mov ds, ax" is in fact executed by guest, not by
vmxassist, it do cause problem for us.

Thanks
Yunhong Jiang

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stephen C. Tweedie
Sent: 2006年11月10日 1:31
To: Keir Fraser
Cc: Yu, Wilfred; Xin, Xiaohui; xen-devel@lists.xensource.com; Herbert Xu; Li,
Susie; Steven Rostedt; Li, Xin B
Subject: Re: [Xen-devel] [Patch] Fix for x86_64 boot failures due to badsegment
setup for protected mode.

Hi,

On Thu, 2006-11-09 at 14:08 +0000, Keir Fraser wrote:
> A smaller patch might have been to implement those VMENTER sanity checks
> inside load_seg(). I''m sure they''re quite simple. 
I checked, as that was going to be my first approach.  Turns out that
they are not actually all that simple, with all sorts of different rules
for base, size, access rights, type, flags and so on, dependent on which
segment it is, whether it''s 16 or 32-bit, etc.  

They aren''t _too_ tricky, but after looking at it some, there are
enough
rules there that I was actually more worried about introducing a
regression going down that route than in the patch I ended up with.

Cheers,
 Stephen



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

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

Jiang, Yunhong wrote:
> This patch caused one problem.
> 
> If the guest change the DS/SS etc between it set cr0.PE and the jump
instruction.
> Considering following code:
>    mov eax, cr0
>    or eax, 0x11
>   mov cr0, eax		---> here enable PE, and old_ctx.ds is cleard
Isn''t this where the vmxassist starts emulating?
>    mov ax, 0x0020
>    mov ds, ax		-> changes the DS here
So we only need to emulate the above change.
>   jmp pword ptr [edi + 0x60]
>   mov ax, word ptr [bx + 0x00a8]
> 
> The vmxassit clear the oldctx.ds_sel when guest enable PE, and when guest
executed the mov ds, ax, the content on oldctx is not updated. Later when the
last instruction, the ds is infact 0x0, not the 0x20 as guest hoped.
> 
> This issue is in fact not caused entirely by this change, since we should
emulate all instructions between the set cr0.PE and the jump instruction. But
because the "mov ds, ax" is in fact executed by guest, not by
vmxassist, it do cause problem for us.
Are you sure about that? I thought vmxassist stated full software
emulation as soon as PE was set.

-- Steve


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

Hi,

On Fri, 2006-11-10 at 22:39 +0800, Jiang, Yunhong wrote:
> This patch caused one problem.
> 
> If the guest change the DS/SS etc between it set cr0.PE and the jump
instruction.
Hmm...  Do you know how much of a problem that causes in practice?
Which guests have that behaviour?
> Considering following code:
>    mov eax, cr0
>    or eax, 0x11
>   mov cr0, eax		---> here enable PE, and old_ctx.ds is cleard
>    mov ax, 0x0020
>    mov ds, ax		-> changes the DS here
Well, we''ve got commit log comments for the "pop %es" case:

2) In
current vmxassist, when entering VM86_PROTECTED_TO_REAL, we need to
decode every instruction manually until we catch instructions like
jmpl to reset cs to really return to real mode.

So I''m afraid I just assumed that we wouldn''t need to deal
with ds in
real life, since we haven''t added emulation for that so far.  Is that
emulation we need to add as a matter of some urgency, then?

--Stephen



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

Hi,

On Fri, 2006-11-10 at 16:09 +0000, Stephen C. Tweedie wrote:
> So I''m afraid I just assumed that we wouldn''t need to
deal with ds in
> real life, since we haven''t added emulation for that so far.  Is
that
> emulation we need to add as a matter of some urgency, then?
In particular, do you know why we have to emulate pop %es when we still
depend on modifying ds without emulation?

--Stephen



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