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 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.

> 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.
> 
> ... everything else treats the memory operand as 32bit, and uses the
> bottom half of the internal buffer, and generally does the right thing.

No, if I'm getting right what you say it was the other way around:
Right now we
- read guest memory (ahead of the big switch()); that's always a 32-bit
  access for VEX-encoded GPR insns in 32-bit code (the value is read
  into an internal field which is pre-set to zero, i.e. when used as a
  64-bit quantity, it's effectively the zero-extended value that was
  read from guest memory),
- emit a VEX-encoded insn into the stub with VEX.W set,
- execute that insn, resulting in a 64-bit memory access to the internal
  field, where as per above the upper half is zero.
It's only this way that it can be explained why the new testcase added
would previously have failed (wrongly set EFLAGS.SF).

Jan