Re: [PATCH v8 13/20] KVM: x86: Reject EVEX-prefixed instructions
From: Jim Mattson
Date: Fri Nov 06 2026 - 00:02:43 EST
On Wed, Sep 30, 2026 at 4:54 PM Chang S. Bae <chang.seok.bae@xxxxxxxxx> wrote:
>
> Explicitly mark EVEX-prefixed opcodes (0x62) as unsupported.
>
> Signed-off-by: Chang S. Bae <chang.seok.bae@xxxxxxxxx>
> ---
> arch/x86/kvm/emulate.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index eba4e9b7cd5c..f0d5a40eba27 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -5052,6 +5052,11 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void *insn, int insn_len, int
> if (opcode.flags & ModRM)
> ctxt->modrm = insn_fetch(u8, ctxt);
>
> + /* EVEX-prefixed instructions are not implemented */
> + if (ctxt->opcode_len == 1 && ctxt->b == 0x62 &&
> + (mode == X86EMUL_MODE_PROT64 || (ctxt->modrm & 0xc0) == 0xc0))
> + opcode.flags = NotImpl;
What is this patch actually doing? opcode_table[0x62] is already N
(NotImpl). Moreover, because opcode_table[0x62] does not have the ModRM
flag and init_decode_cache() does not clear ctxt->modrm, "(ctxt->modrm &
0xc0) == 0xc0" in non-64-bit mode inspects a stale ctxt->modrm from
whatever instruction was emulated previously.
If the intent is to mark opcode_table[0x62] with No64 (or NoRex2) so
that REX2 (with M0=0) followed by 0x62 raises #UD, then:
1. opcode_table[0x62] actually needs that flag, and
2. this EVEX check must be gated on ctxt->rex_prefix != REX2_PREFIX,
or else it will clobber opcode.flags with NotImpl on "D5 00 62" and
return EMULATION_FAILED instead of injecting #UD.