your patch "KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode"

your patch "KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode"

[Jan Beulich]

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?

Jan

Re: your patch "KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode"

[Sean Christopherson]

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