Incorrect UBIT handling for VSIB instructions

[flobernd]

Hi there,

while running some tests in Zydis, we found a few instructions that do decode in Zydis, but not in XED. After looking at it in detail, I think this might be a bug in XED.

For example:

• 62 EA F9 01 93 04 11 (XED: vgatherqpd xmm16, k1, qword ptr [r17+xmm18*1])
• 62 62 FD 06 A0 A4 A4 3E 25 62 62 (XED: vpscatterdq qword ptr ss:[rsp+xmm20*4+0x6262253E] {k6}, xmm28)

All of these instructions have EVEX.U set to 0 which is not allowed for "legacy EVEX" instructions, but XED still decodes them.

It even seems that you even added UBIT=1 to the patterns of these instructions, but it seems to be ignored when decoding:

VPSCATTERDQ
PATTERN:    EVV 0xA0 V66 V0F38 MOD[mm] MOD!=3 UBIT=1 REG[rrr] RM[0b100] RM=4 BCRC=0   VL128  W1 UISA_VMODRM_XMM() eanot16  NOVSR  ZEROING=0  ESIZE_64_BITS() NELEM_GSCAT()

We have not checked further to see if only VSIB instructions are affected or if this behavior applies to other "legacy evex" instructions as well.

cc @mappzor

[marjevan]

Hi,

According to Intel's APX public specification, instructions with ModRM.MOD != 3 reinterpret the U bit as X4, which is ignored if not used by the instruction.

From the APX spec:

As shown below, the X4 (or U) bit is not used in the VSIB memory address calculation:

In XED, the ILD scanner applies the same reinterpretation when APX is enabled, consistent with the spec: https://github.com/intelxed/xed/blob/b86dd5014463d954bc8898d2376b14852d26facd/src/dec/xed-ild.c#L1392-L1398

[flobernd]

Hi @marjevan ,

thanks a lot for clarifying!

Our UBIT check was too strict for "legacy" EVEX instructions and did not consider the modrm.mod != 3 case.