linux-kernel - Re: [PATCH RFC v1 16/20] KVM: x86: Decode REX2 prefix in the emulator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABgObfYYGTvkYpeyqLSr9JgKMDA_STSff2hXBNchLZuKFU+MMA@mail.gmail.com>
Date: Tue, 18 Nov 2025 00:33:23 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: "Chang S. Bae" <chang.seok.bae@...el.com>
Cc: kvm <kvm@...r.kernel.org>, 
	"Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>, Sean Christopherson <seanjc@...gle.com>, 
	"Gao, Chao" <chao.gao@...el.com>, Zhao Liu <zhao1.liu@...el.com>
Subject: Re: [PATCH RFC v1 16/20] KVM: x86: Decode REX2 prefix in the emulator

Il lun 17 nov 2025, 21:01 Chang S. Bae <chang.seok.bae@...el.com> ha scritto:
>
> While rebasing onto your VEX series, I noticed a couple of missings:
>
>    (1) Jumping directly to the decode path skips the ctxt->op_bytes
>        setup.
>    (2) It also removes the logic that detects the invalid sequence:
>        REX2->REX (unless intentional).
>
> Perhaps it makes sense to simply continue prefix parsing. Then, at
> 'done_prefixes', we can check the M bit next to the W-bit check and jump
> to the two-byte decode path.
>
> I’ve attached a revised diff on top of the VEX series.

Yes, that works for me with one change---after REX2 is processed there
should be a "ctxt->b = insn_fetch(u8, ctxt); goto done_prefixes;"
because REX2 is always the last prefix.

This also means that checking "(ctxt->rex_prefix == REX2_PREFIX &&
!(ctxt->rex_bits & REX_M))" is unnecessary. Instead the second REX2
prefix's 0xd5 byte can be treated as a No64 opcode and will trigger
#UD. In fact this is what the manual says: "a REX prefix byte (0x4*),
a VEX prefix byte (0xC4 or 0xC5), an EVEX prefix byte (0x62), or
another REX2 prefix byte (0xD5) following a REX2 prefix with REX2.M0 =
0 must #UD, because none of those bytes is the opcode of a valid
instruction in legacy map 0 in 64-bit mode".

So all you need to do is add the No64 flag to entries 0x40...0x4F of
the opcode_table, and then "goto done_prefixes" will cover that
sentence nicely.

Paolo