On Wed, Feb 10, 2021, Jan Beulich wrote: > I've noticed this patch while routinely screening the stable > kernel logs for issues we may also need to fix in Xen. Isn't > a similar change needed in SYSCALL emulation when going from > compat to 64-bit mode? Yep, it is. AMD's APM explicitly states that compat always transitions to long mode. I believe em_sysexit() is technically buggy as well, though in the opposite way, as it doesn't set ctxt->mode when switching from long mode to compat mode. But, it explicitly truncates rdx before assigning to rip so that's likely a benign bug, at least for now. I don't see anything in em_rsm() that will fixup ctxt->mode, so I'm guessing an SMI with a 64-bit RIP will be fatal, too. __emulate_int_real() can't switch mode, and INTn and company aren't emulated in protected mode. assign_eip_far() does update ctxt->mode, so far call/ret aren't broken. Given the number of flows that can potentially affect mode, and the difficulty in testing them, I feel like x86_emulate_insn() should handle refreshing the mode, or at least do a sanity check to verify that it was already updated. Side topic, I'm super curious why Intel lets SYSRET return to compat mode, when SYSCALL #UDs in compat mode...
