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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.11.2024 14:32, Andrew Cooper wrote:
> 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.

That's to _replace_ the "Internal state ..." sentence then, rather than an
added separate sentence / paragraph? It says exactly the same, after all.

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

Thanks, but I'll wait some for clarification above.

Jan