Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 14 Jan 2015 12:24:52 -0800 | Subject | Re: [PATCH 3.19 v2 2/3] x86, mpx: Short-circuit the instruction decoder for unexpected opcodes |
| |
On Wed, Jan 14, 2015 at 11:43 AM, Dave Hansen <dave.hansen@linux.intel.com> wrote: > On 01/12/2015 03:57 PM, Andy Lutomirski wrote: >>>> >> - /* >>>> >> - * We only _really_ need to decode bndcl/bndcn/bndcu >>>> >> - * Error out on anything else. >>>> >> - */ >>>> >> - if (insn->opcode.bytes[0] != 0x0f) >>>> >> - goto bad_opcode; >>>> >> - if ((insn->opcode.bytes[1] != 0x1a) && >>>> >> - (insn->opcode.bytes[1] != 0x1b)) >>>> >> - goto bad_opcode; >>> > >>> > Otherwise, this looks OK to me. Have you tested this at all? I know >>> > you don't have any MPX hardware, but you can still hack something in to >>> > point the instruction decoder at an MPX binary. >> I haven't tested this at all. ISTM it's more likely that any test >> hack I write for this will mask any problem than that it will be a >> real test. > > This is completely and totally broken when there is an instruction > prefix. Instruction prefixes which occur before the opcodes in the > buffer, so buf[0] is not necessarily insn->opcode.bytes[0]. > > This was immediately obvious when I actually ran this code for the first > time, even on hardware without MPX.
My apologies -- I misunderstood what insn->opcode.bytes did, and I assumed that the original code intentionally did the same thing.
Please drop this patch.
--Andy
-- Andy Lutomirski AMA Capital Management, LLC
| |