Lifting error for instruction MOVSS (x86)

[Boyan-MILANOV]

Binary Ninja Version
Version 2.4.2927-dev

Describe the bug
The LLIL generated for instruction movss xmm0, dword [rel 0x43bfd7] is xmm0 = [0x43bfd7].d . The right hand side [0x43bfd7].d is 32 bits in size while xmm0 is 128 bits long. [0x43bfd7].d should be zero extended to 128 bits, according to the MOVSS instruction reference

To Reproduce
Steps to reproduce the behavior:

1. Generate LLIL for instruction movss xmm0, dword [rel 0x43bfd7] (or any other address)
2. See that the LLIL is xmm0 = [0x43bfd7].d, while we rather expect: xmm0 = zx([0x43bfd7].d)
3. Additionally, the python API can be used to verify that the extend field for [0x43bfd7].d is indeed ImplicitRegisterExtend.NoExtend

Expected behavior
When the second argument of MOVSS is a m32 memory access, the loaded value should be zero extended to 128 bits to match the size of XMM* registers

Version and Platform (required):

• Binary Ninja: 2.4.2927-dev
• OS: macOS
• Version: 11.5.1

[jeffli678]

Thx for the report! I will have a look at it later.

Btw this should be moved to the x86 repository. Which cannot be done on a mobile phone

[xusheng6]

We should see if our IL emulator can catch lifting bugs like this

[xusheng6]

Yeah the movss works differnetly when the second operand changes:

MOVSS xmm1, xmm2 (register → register):
DEST[31:0]      := SRC[31:0]
DEST[MAXVL-1:32] (Unmodified)      ← upper bits PRESERVED

MOVSS xmm1, m32 (memory → register):
DEST[31:0]     := SRC[31:0]
DEST[127:32]   := 0                ← upper 96 bits ZEROED
DEST[MAXVL-1:128] (Unmodified)

MOVSS m32, xmm1 (register → memory):
DEST[31:0] := SRC[31:0]            ← just a 32-bit store