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.coop...@citrix.com> Thanks, but I'll wait some for clarification above. Jan
