* Re: your patch "KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode"
2021-02-10 9:13 your patch "KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode" Jan Beulich
@ 2021-02-11 16:43 ` Sean Christopherson
0 siblings, 0 replies; 2+ messages in thread
From: Sean Christopherson @ 2021-02-11 16:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: Jonny Barker, KVM
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...
^ permalink raw reply [flat|nested] 2+ messages in thread