kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: stsp <stsp2@yandex.ru>, kvm list <kvm@vger.kernel.org>
Subject: Re: guest/host mem out of sync on core2duo?
Date: Fri, 18 Jun 2021 22:32:38 +0000	[thread overview]
Message-ID: <YM0fBtqYe+VyPME7@google.com> (raw)
In-Reply-To: <CALMp9eQxys64U-r5xdF_wdunqn8ynBoOBPRDSjTDMh-gF3EEpg@mail.gmail.com>

On Fri, Jun 18, 2021, Jim Mattson wrote:
> On Fri, Jun 18, 2021 at 2:55 PM stsp <stsp2@yandex.ru> wrote:
> >
> > 19.06.2021 00:07, Jim Mattson пишет:
> > > On Fri, Jun 18, 2021 at 9:02 AM stsp <stsp2@yandex.ru> wrote:
> > >
> > >> Here it goes.
> > >> But I studied it quite thoroughly
> > >> and can't see anything obviously
> > >> wrong.
> > >>
> > >>
> > >> [7011807.029737] *** Guest State ***
> > >> [7011807.029742] CR0: actual=0x0000000080000031,
> > >> shadow=0x00000000e0000031, gh_mask=fffffffffffffff7
> > >> [7011807.029743] CR4: actual=0x0000000000002041,
> > >> shadow=0x0000000000000001, gh_mask=ffffffffffffe871
> > >> [7011807.029744] CR3 = 0x000000000a709000
> > >> [7011807.029745] RSP = 0x000000000000eff0  RIP = 0x000000000000017c
> > >> [7011807.029746] RFLAGS=0x00080202         DR7 = 0x0000000000000400
> > >> [7011807.029747] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
> > >> [7011807.029749] CS:   sel=0x0097, attr=0x040fb, limit=0x000001a0,
> > >> base=0x0000000002110000
> > >> [7011807.029751] DS:   sel=0x00f7, attr=0x0c0f2, limit=0xffffffff,
> > >> base=0x0000000000000000
> > > I believe DS is illegal. Per the SDM, Checks on Guest Segment Registers:
> > >
> > > * If the guest will not be virtual-8086, the different sub-fields are
> > > considered separately:
> > >    - Bits 3:0 (Type).
> > >      * DS, ES, FS, GS. The following checks apply if the register is usable:
> > >        - Bit 0 of the Type must be 1 (accessed).
> >
> > That seems to be it, thank you!
> > At least for the minimal reproducer
> > I've done.
> >
> > So only with unrestricted guest its
> > possible to ignore that field?
> 
> The VM-entry constraints are the same with unrestricted guest.
> 
> Note that *without* unrestricted guest, kvm will generally have to
> emulate the early guest protected mode code--until the last vestiges
> of real-address mode are purged from the descriptor cache. Maybe it
> fails to set the accessed bits in the LDT on emulated segment register
> loads?

Argh!  Check out this gem:

	/*
	 *   Fix the "Accessed" bit in AR field of segment registers for older
	 * qemu binaries.
	 *   IA32 arch specifies that at the time of processor reset the
	 * "Accessed" bit in the AR field of segment registers is 1. And qemu
	 * is setting it to 0 in the userland code. This causes invalid guest
	 * state vmexit when "unrestricted guest" mode is turned on.
	 *    Fix for this setup issue in cpu_reset is being pushed in the qemu
	 * tree. Newer qemu binaries with that qemu fix would not need this
	 * kvm hack.
	 */
	if (is_unrestricted_guest(vcpu) && (seg != VCPU_SREG_LDTR))
		var->type |= 0x1; /* Accessed */


KVM fixes up segs when unrestricted guest is enabled, but otherwise leaves 'em
be, presumably because it has the emulator to fall back on for invalid state.
Guess what's missing in the invalid state check...

I think this should do it:

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 68a72c80bd3f..a753b9859826 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -3427,6 +3427,8 @@ static bool data_segment_valid(struct kvm_vcpu *vcpu, int seg)
                if (var.dpl < rpl) /* DPL < RPL */
                        return false;
        }
+       if (!(var.type & VMX_AR_TYPE_ACCESSES_MASK))
+               return false;

        /* TODO: Add other members to kvm_segment_field to allow checking for other access
         * rights flags

  parent reply	other threads:[~2021-06-18 22:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-12 22:49 guest/host mem out of sync on core2duo? stsp
2021-06-13 12:36 ` stsp
2021-06-14 17:06 ` Sean Christopherson
2021-06-14 17:32   ` stsp
2021-06-17 14:42     ` Sean Christopherson
2021-06-18 15:59       ` stsp
2021-06-18 21:07         ` Jim Mattson
2021-06-18 21:55           ` stsp
2021-06-18 22:06             ` Jim Mattson
2021-06-18 22:26               ` stsp
2021-06-18 22:32               ` Sean Christopherson [this message]
2021-06-19  0:11                 ` stsp
2021-06-19  0:54                   ` Sean Christopherson
2021-06-19  9:18                     ` stsp
2021-06-21  2:34           ` exception vs SIGALRM race (was: Re: guest/host mem out of sync on core2duo?) stsp
2021-06-21 22:33             ` Jim Mattson
2021-06-21 23:32               ` stsp
2021-06-22  0:27               ` stsp
2021-06-28 21:47                 ` Jim Mattson
2021-06-28 21:50                   ` stsp
2021-06-28 22:00                   ` stsp
2021-06-28 22:27                     ` Jim Mattson
2021-07-06 16:28                       ` Paolo Bonzini
2021-07-06 22:22                         ` stsp
2021-07-06 23:41                           ` Paolo Bonzini
2021-06-23 23:38               ` exception vs SIGALRM race (with test-case now!) stsp
2021-06-24  0:11                 ` stsp
2021-06-24  0:25                   ` stsp
2021-06-24 18:05                     ` exception vs SIGALRM race on core2 CPUs (with qemu-based test-case this time!) stsp
2021-06-24 18:07                     ` stsp
2021-06-25 23:35                       ` exception vs SIGALRM race on core2 CPUs (with fix!) stsp
2021-06-26  0:15                         ` Jim Mattson
2021-06-26  0:35                           ` stsp
2021-06-26 21:50                           ` stsp
2021-06-27 12:13                           ` stsp
2021-06-26 14:03               ` exception vs SIGALRM race (another patch) stsp

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=YM0fBtqYe+VyPME7@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=stsp2@yandex.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).