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.coop...@citrix.com> ~Andrew
