All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: kvm@vger.kernel.org
Subject: [Bug 211467] New: Regression affecting 32->64 bit SYSENTER on AMD
Date: Fri, 29 Jan 2021 20:50:12 +0000	[thread overview]
Message-ID: <bug-211467-28872@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=211467

            Bug ID: 211467
           Summary: Regression affecting 32->64 bit SYSENTER on AMD
           Product: Virtualization
           Version: unspecified
    Kernel Version: 5.8-rc1
          Hardware: IA-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: kvm
          Assignee: virtualization_kvm@kernel-bugs.osdl.org
          Reporter: jonny@magicstring.co.uk
        Regression: No

For obscure legacy reasons I am running MacOS 10.6.8 in a qemu VM, and since
commit fede8076aab4c2280c673492f8f7a2e87712e8b4 the guest crashes 30 seconds or
so after boot.

It seems that the crash is triggered by starting a i386 program within the
x86_64 XNU kernel, which makes syscalls using the SYSENTER instruction. The
emulate.c change within the problematic commit truncates the intended EIP
(0xffffff80002e3ad0 corresponding to the _hi64_sysenter symbol in the guest's
mach_kernel) down to 32 bits, and the guest then crashes - commenting out the
truncation fixes the problem.

This doesn't seem be a problem on Intel VT since there SYSENTER isn't trapped
by KVM, but it fails on an AMD Ryzen 5600X. It is also presumably not a problem
with Linux guests, since the EIP used for Linux SYSENTER syscalls fits within
32 bits (I think).

I don't know what problem the truncation is intended to fix, but I assume it
isn't meant to interfere with SYSENTER. I've looked through all the
documentation I can find and am not certain whether SYSENTER is specified to
copy the full 64 bits from IA32_SYSENTER_EIP when used in 32 bit mode on a CPU
with 64 bit support, but I assume it is if the 32->64bit XNU SYSENTER syscall
is intended to work.

Also, ctxt->mode is still set to X86EMUL_MODE_PROT32 at the point that the
truncation is done, despite em_sysenter having updated CS to enter long mode.
Perhaps em_sysenter should use assign_eip_far to set ctxt->_eip instead, to
ensure that the mode is updated? (if that is indeed correct behaviour?). The
truncation would then not take place and the problem would not occur.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2021-01-29 20:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 20:50 bugzilla-daemon [this message]
2021-01-29 21:47 ` [Bug 211467] Regression affecting 32->64 bit SYSENTER on AMD bugzilla-daemon
2021-01-29 23:38 ` bugzilla-daemon
2021-02-01 10:31 ` bugzilla-daemon
2021-02-01 21:16 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-211467-28872@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.