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