xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [PATCH 01/10] x86/emul: Correct the decoding of vlddqu
Date: Mon, 27 Mar 2017 10:56:29 +0100	[thread overview]
Message-ID: <1490608598-11197-2-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1490608598-11197-1-git-send-email-andrew.cooper3@citrix.com>

vlddqu is encoded with 0xf2 which causes it to fall into the Scalar general
case in x86_decode_twobyte().  However, it really does have just two operands,
so must remain TwoOp

AFL discovered that the instruction c5 5b f0 3c e5 95 0a cd 63 was considered
valid despite it being a two operand instruction and VEX.vvvv having the value
11.  The resulting use in a stub yielded #UD.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>

From manually decoding the instruciton, I believe Xen's interpretation of
disp32(none*8) is correct.  binutils 2.25 (Debian Jessie) yields:

   0:       c5 5b f0 3c e5 95 0a        vlddqu 0x63cd0a95(,%riz,8),%xmm15
   7:       cd 63

where it has accounted for disp32 in its decode of instruction, but failed to
properly move its instruction pointer on.

Intel XED OTOH simply gives up with:

  ERROR: GENERAL_ERROR Could not decode at offset: 0x0 PC: 0x0:
  [C55BF03CE5950ACD63000000000000]
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index bb67be6..497cc77 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2310,7 +2310,8 @@ x86_decode_twobyte(
     case 0x7f:
     case 0xc2 ... 0xc3:
     case 0xc5 ... 0xc6:
-    case 0xd0 ... 0xfe:
+    case 0xd0 ... 0xef:
+    case 0xf1 ... 0xfe:
         ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
         break;
 
@@ -2332,9 +2333,9 @@ x86_decode_twobyte(
         if ( vex.pfx == vex_f3 ) /* movq xmm/m64,xmm */
         {
     case X86EMUL_OPC_VEX_F3(0, 0x7e): /* vmovq xmm/m64,xmm */
-            state->desc = DstImplicit | SrcMem | Mov;
+            state->desc = DstImplicit | SrcMem | TwoOp;
             state->simd_size = simd_other;
-            /* Avoid the state->desc adjustment below. */
+            /* Avoid the state->desc clobbering of TwoOp below. */
             return X86EMUL_OKAY;
         }
         break;
@@ -2374,11 +2375,25 @@ x86_decode_twobyte(
     case X86EMUL_OPC_VEX_66(0, 0xc4): /* vpinsrw */
         state->desc = DstReg | SrcMem16;
         break;
+
+    case 0xf0:
+        ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+        if ( vex.pfx == vex_f2 ) /* lddqu mem,xmm */
+        {
+        /* fall through */
+    case X86EMUL_OPC_VEX_F2(0, 0xf0): /* vlddqu mem,{x,y}mm */
+            state->desc = DstImplicit | SrcMem | TwoOp;
+            state->simd_size = simd_other;
+            /* Avoid the state->desc clobbering of TwoOp below. */
+            return X86EMUL_OKAY;
+        }
+        break;
     }
 
     /*
      * Scalar forms of most VEX-encoded TwoOp instructions have
-     * three operands.
+     * three operands.  Those which do really have two operands
+     * should have exited earlier.
      */
     if ( state->simd_size && vex.opcx &&
          (vex.pfx & VEX_PREFIX_SCALAR_MASK) )
-- 
2.1.4


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

  reply	other threads:[~2017-03-27  9:56 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27  9:56 [PATCH 00/10] x86 emulation bugfixes and fuzzer improvements Andrew Cooper
2017-03-27  9:56 ` Andrew Cooper [this message]
2017-03-27 11:24   ` [PATCH 01/10] x86/emul: Correct the decoding of vlddqu Jan Beulich
2017-03-27 12:10     ` Andrew Cooper
2017-03-27 12:30       ` Jan Beulich
2017-03-27  9:56 ` [PATCH 02/10] x86/emul: Add feature check for clzero Andrew Cooper
2017-03-27 11:25   ` Jan Beulich
2017-03-27 11:28   ` Jan Beulich
2017-03-27 12:13     ` Andrew Cooper
2017-03-27 12:31       ` Jan Beulich
2017-03-27 13:40         ` Andrew Cooper
2017-03-27  9:56 ` [PATCH 03/10] tools/insn-fuzz: Don't use memcpy() for zero-length reads Andrew Cooper
2017-03-27 11:02   ` George Dunlap
2017-03-27 11:05     ` Andrew Cooper
2017-03-27 11:32       ` Jan Beulich
2017-03-27 12:22         ` Andrew Cooper
2017-03-27 12:35           ` Jan Beulich
2017-03-27 11:36   ` Jan Beulich
2017-03-27 12:14     ` Andrew Cooper
2017-03-27  9:56 ` [PATCH 04/10] tools/insn-fuzz: Avoid making use of static data Andrew Cooper
2017-03-27 11:39   ` Jan Beulich
2017-03-27  9:56 ` [PATCH 05/10] tools/insn-fuzz: Fix a stability bug in afl-clang-fast mode Andrew Cooper
2017-03-27 11:41   ` Jan Beulich
2017-03-27  9:56 ` [PATCH 06/10] tools/insn-fuzz: Correct hook prototypes, and assert() appropriate segments Andrew Cooper
2017-03-27 11:48   ` Jan Beulich
2017-03-27 12:49     ` Andrew Cooper
2017-03-27  9:56 ` [PATCH 07/10] tools/insn-fuzz: Provide IA32_DEBUGCTL consistently to the emulator Andrew Cooper
2017-03-27 11:53   ` Jan Beulich
2017-03-27 12:53     ` Andrew Cooper
2017-03-27  9:56 ` [PATCH 08/10] tools/insn-fuzz: Fix assertion failures in x86_emulate_wrapper() Andrew Cooper
2017-03-27 12:01   ` Jan Beulich
2017-03-27  9:56 ` [PATCH 09/10] tools/x86emul: Advertise more CPUID features for testing purposes Andrew Cooper
2017-03-27 11:20   ` George Dunlap
2017-03-27 12:13     ` Jan Beulich
2017-03-27 12:56       ` George Dunlap
2017-03-27 13:03         ` Andrew Cooper
2017-03-27 13:08           ` George Dunlap
2017-03-27 13:42           ` Jan Beulich
2017-03-27 13:49             ` Andrew Cooper
2017-03-27 13:37       ` Andrew Cooper
2017-03-27 13:45         ` Jan Beulich
2017-03-27 12:09   ` Jan Beulich
2017-03-27 13:01     ` Andrew Cooper
2017-03-27 13:40       ` Jan Beulich
2017-03-27  9:56 ` [PATCH 10/10] tools/insn-fuzz: Always use x86_swint_emulate_all Andrew Cooper
2017-03-27 11:00   ` George Dunlap
2017-03-27 13:09     ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1490608598-11197-2-git-send-email-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).