x86/emulate: don't assume that addr_size == 32 implies protected mode Callers of x86_emulate() generally define addr_size based on the code segment. In vm86 mode, the code segment is set by the hardware to be 16-bits; but it is entirely possible to enable protected mode, set the CS to 32-bits, and then disable protected mode. (This is commonly called "unreal mode".) But the instruction decoder only checks for protected mode when addr_size == 16. So in unreal mode, hardware will throw a #UD for VEX prefixes, but our instruction decoder will decode them, triggering an ASSERT() further on in _get_fpu(). (With debug=n the emulator will incorrectly emulate the instruction rather than throwing a #UD, but this is only a bug, not a crash, so it's not a security issue.) Teach the instruction decoder to check that we're in protected mode, even if addr_size is 32. While we're here, replace the open-coded protected mode check with in_protmode(). Signed-off-by: George Dunlap Split real mode and VM86 mode handling, as VM86 mode is strictly 16-bit at all times. Re-base. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2288,11 +2288,11 @@ x86_decode( default: BUG(); /* Shouldn't be possible. */ case 2: - if ( in_realmode(ctxt, ops) || (state->regs->_eflags & EFLG_VM) ) + if ( state->regs->_eflags & EFLG_VM ) break; /* fall through */ case 4: - if ( modrm_mod != 3 ) + if ( modrm_mod != 3 || in_realmode(ctxt, ops) ) break; /* fall through */ case 8: