On 14/11/2024 9:39 am, Jan Beulich wrote: > 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.
Ideally, yes. I think it's clearer this way around. ~Andrew
