Re: [PATCH 2/2] x86emul: ignore VEX.W for BMI{1,2} insns in 32-bit mode

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/11/2024 1:31 pm, Andrew Cooper wrote:
> On 13/11/2024 8:01 am, Jan Beulich wrote:
>> On 13.11.2024 01:24, Andrew Cooper wrote:
>>> On 12/11/2024 3:00 pm, Jan Beulich wrote:
>>>> While result values and other status flags are unaffected as long as we
>>>> can ignore the case of registers having their upper 32 bits non-zero
>>>> outside of 64-bit mode, EFLAGS.SF may obtain a wrong value when we
>>>> mistakenly re-execute the original insn with VEX.W set.
>>>>
>>>> Note that the memory access, if any, is correctly carried out as 32-bit
>>>> regardless of VEX.W.
>>> I don't understand why this is true.
>> This talks about the access to guest memory, which is op_bytes based.
>> And op_bytes determination handles VEX.W correctly afaics. I've added
>> "guest" near the start of the sentence for clarification.
> Ah - that makes things much clearer.
>
> I had neglected to consider the access to guest memory.
>
> In addition to a "guest" earlier, I'd suggest having a new paragraph at
> this point, and ...
>
>>> If we write out a VEX.W=1 form of BEXTR/etc and emulate while in 64bit
>>> mode, it will have an operand size of 64.
>>>
>>> I can believe that ...
>>>
>>>>  Internal state also isn't leaked, as the field the
>>>> memory value is read into (which is then wrongly accessed as a 64-bit
>>>> quantity when executing the stub) is pre-initialized to zero.
> ... this reading:
>
> "The emulator-local memory operand will be accessed as a 64-bit
> quantity, but it is pre-initialised to zero so no internal state an leak"
>
> or similar.

Oh, and Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

~Andrew