Invalid op code emulation for HVM guest and GPF

Invalid op code emulation for HVM guest and GPF

[Mukesh Rathor]

Hey Keir,

DTRACE in linux/solaris guests use invalid op code sequence:

opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) 

to receive UD, but they get GPF instead. (xen 4.1.2)

Looking at hvm_emulate_one() I see place where it generates GPF if not
expected sequence. Do you know quickly what can be done to deliver UD
for the above sequence, or what single byte they can use to generate
UD? (int 6 is two byte instr and doesn't work for them).

thanks a lot,
Mukesh

Re: Invalid op code emulation for HVM guest and GPF

[Andrew Cooper]

On 23/03/12 18:44, Mukesh Rathor wrote:
> Hey Keir,
>
> DTRACE in linux/solaris guests use invalid op code sequence:
>
> opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) 
>
> to receive UD, but they get GPF instead. (xen 4.1.2)
>
> Looking at hvm_emulate_one() I see place where it generates GPF if not
> expected sequence. Do you know quickly what can be done to deliver UD
> for the above sequence, or what single byte they can use to generate
> UD? (int 6 is two byte instr and doesn't work for them).
>
> thanks a lot,
> Mukesh

There is the UD2 instruction 0x0F 0x0B which is specifically designed to
cause a #UD exception.

I am not sure what you mean by "single byte", as the example sequence is
not a single byte instruction.  The LOCK is an instruction prefix,
making the first NOP a 2 byte instruction, followed by three 1byte
instructions.

As for the operation of LOCK NOP, Intel manual 2B defines this to cause
an #UD exception, so that is a bug in Xen.

It has been long time since I have played about in that code - I will
see if I can remember enough to fix this issue, but others will probably
be faster.

~Andrew

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

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Re: Invalid op code emulation for HVM guest and GPF

[Keir Fraser]

On 23/03/2012 18:44, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> Hey Keir,
> 
> DTRACE in linux/solaris guests use invalid op code sequence:
> 
> opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP)
> 
> to receive UD, but they get GPF instead. (xen 4.1.2)
> 
> Looking at hvm_emulate_one() I see place where it generates GPF if not
> expected sequence. Do you know quickly what can be done to deliver UD
> for the above sequence, or what single byte they can use to generate
> UD? (int 6 is two byte instr and doesn't work for them).

You'll have to point out the path taken. AFAICS the sequence will cause a
#UD trap into Xen, which will execute vmx_vmexit_ud_intercept(), should get
X86EMUL_UNHANDLEABLE from hvm_emulate_one() and then inject the #UD back up
into the guest.

I don't see where the #GP would come from: certainly hvm_emulate_one()
itself doesn't appear to generate any guest exceptions. Is it coming from
the emulator itself? Might be a bug to be fixed if so.

 -- Keir

> thanks a lot,
> Mukesh

Re: Invalid op code emulation for HVM guest and GPF

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

Patch attached.

Not tested, but seems logically correct.

@Mukesh: Do you mind testing please?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


[-- Attachment #2: x86_emulate_nop.patch --]
[-- Type: text/x-patch, Size: 801 bytes --]

# HG changeset patch
# Parent 0ecb8ffe61b2ffff4331fcf49487c956ccb297a0
x86_emulate: Force #UD if lock prefix used with NOP instruction.

DTRACE uses 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) to try and recieve a
#UD, but currently get GPF instead.

Fix x86_emulate, as #UD is the correct exception in this case.

Reported-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 0ecb8ffe61b2 xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2255,6 +2255,7 @@ x86_emulate(
         break;
 
     case 0x90: /* nop / xchg %%r8,%%rax */
+        generate_exception_if(lock_prefix, EXC_UD, -1);
         if ( !(rex_prefix & 1) )
             break; /* nop */
 

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: Invalid op code emulation for HVM guest and GPF

[Mukesh Rathor]

On Fri, 23 Mar 2012 19:17:47 +0000
Keir Fraser <keir.xen@gmail.com> wrote:

> You'll have to point out the path taken. AFAICS the sequence will

Ok, I can do that and let you know.


>I don't see where the #GP would come from: certainly hvm_emulate_one()

It may be coming from:

x86_emulate():
        * The only implicit-operands instructions allowed a LOCK prefix are
        * CMPXCHG{8,16}B, MOV CRn, MOV DRn.
        */
        generate_exception_if(
            lock_prefix &&
            ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn */
            (b != 0xc7),                  /* CMPXCHG{8,16}B */
            EXC_GP, 0);


thanks,
Mukesh

Re: Invalid op code emulation for HVM guest and GPF

[Mukesh Rathor]

On Fri, 23 Mar 2012 19:20:58 +0000
Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> Patch attached.
> 
> Not tested, but seems logically correct.
> 
> @Mukesh: Do you mind testing please?
> 

Sure. Let me build xen with fix and give to Dtrace developers.

thanks,
Mueksh

Re: Invalid op code emulation for HVM guest and GPF

[Andrew Cooper]

On 23/03/12 19:30, Mukesh Rathor wrote:
> On Fri, 23 Mar 2012 19:20:58 +0000
> Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>> Patch attached.
>>
>> Not tested, but seems logically correct.
>>
>> @Mukesh: Do you mind testing please?
>>
> Sure. Let me build xen with fix and give to Dtrace developers.
>
> thanks,
> Mueksh

Sadly, given your other email, I doubt it will work, because of the big
catch all regarding the lock prefix.

A brief scan over the Intel manuals and I cant see a case where an
incorrect LOCK prefix would cause #GPF rather than #UD.

Perhaps try changing it to EXP_UD instead of EXP_GP.  (Although I make
no guarantee that this wont cause a lot of things to break.)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Re: Invalid op code emulation for HVM guest and GPF

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On 23/03/12 19:38, Andrew Cooper wrote:
> Sadly, given your other email, I doubt it will work, because of the big
> catch all regarding the lock prefix.
>
> A brief scan over the Intel manuals and I cant see a case where an
> incorrect LOCK prefix would cause #GPF rather than #UD.
>
> Perhaps try changing it to EXP_UD instead of EXP_GP.  (Although I make
> no guarantee that this wont cause a lot of things to break.)

Try this patch instead.

I have still yet to find a single example in either manual 2A or B where
an invalid lock prefix would cause a #GPF rather than #UD

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


[-- Attachment #2: x86_emulate_nop.patch --]
[-- Type: text/x-patch, Size: 1252 bytes --]

diff -r 0ecb8ffe61b2 xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1429,7 +1429,7 @@ x86_emulate(
     }
 
     /* Lock prefix is allowed only on RMW instructions. */
-    generate_exception_if((d & Mov) && lock_prefix, EXC_GP, 0);
+    generate_exception_if((d & Mov) && lock_prefix, EXC_UD, 0);
 
     /* ModRM and SIB bytes. */
     if ( d & ModRM )
@@ -1712,12 +1712,12 @@ x86_emulate(
             lock_prefix &&
             ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn */
             (b != 0xc7),                  /* CMPXCHG{8,16}B */
-            EXC_GP, 0);
+            EXC_UD, 0);
         dst.type = OP_NONE;
         break;
 
     case DstReg:
-        generate_exception_if(lock_prefix, EXC_GP, 0);
+        generate_exception_if(lock_prefix, EXC_UD, 0);
         dst.type = OP_REG;
         if ( d & ByteOp )
         {
@@ -1773,7 +1773,7 @@ x86_emulate(
         dst = ea;
         if ( dst.type == OP_REG )
         {
-            generate_exception_if(lock_prefix, EXC_GP, 0);
+            generate_exception_if(lock_prefix, EXC_UD, 0);
             switch ( dst.bytes )
             {
             case 1: dst.val = *(uint8_t  *)dst.reg; break;

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: Invalid op code emulation for HVM guest and GPF

[Keir Fraser]

On 23/03/2012 19:58, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> On 23/03/12 19:38, Andrew Cooper wrote:
>> Sadly, given your other email, I doubt it will work, because of the big
>> catch all regarding the lock prefix.
>> 
>> A brief scan over the Intel manuals and I cant see a case where an
>> incorrect LOCK prefix would cause #GPF rather than #UD.
>> 
>> Perhaps try changing it to EXP_UD instead of EXP_GP.  (Although I make
>> no guarantee that this wont cause a lot of things to break.)
> 
> Try this patch instead.
> 
> I have still yet to find a single example in either manual 2A or B where
> an invalid lock prefix would cause a #GPF rather than #UD

Yeah, this is a good fix. The origin of #GP is way back when I was doing a
major weekend hack on extending the emulator for vmx realmode emulation. I
expect in haste I picked the wrong exception type and that has propagated
onward.

I will apply to xen-unstable, and if it seems okay theer it can be
backported for 4.1 and 4.0.

 -- Keir