All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com
Subject: Re: [PATCH] kvm-unit-test: nVMX: Test Selector and Base Address fields of Guest Segment Registers on vmentry of nested guests
Date: Wed, 11 Mar 2020 14:46:57 -0700	[thread overview]
Message-ID: <20200311214657.GJ21852@linux.intel.com> (raw)
In-Reply-To: <0fb906f6-574f-2e2e-4113-e9d883cb713e@oracle.com>

On Wed, Mar 11, 2020 at 01:38:24PM -0700, Krish Sadhukhan wrote:
> 
> On 3/11/20 8:05 AM, Sean Christopherson wrote:
> >>+static void test_guest_segment_sel_fields(void)
> >>+{
> >>+	u16 sel_saved;
> >>+	u16 sel;
> >>+
> >>+	sel_saved = vmcs_read(GUEST_SEL_TR);
> >>+	sel = sel_saved | 0x4;
> >>+	TEST_SEGMENT_SEL(GUEST_SEL_TR, "GUEST_SEL_TR", sel, sel_saved);
> >>+
> >>+	sel_saved = vmcs_read(GUEST_SEL_LDTR);
> >>+	sel = sel_saved | 0x4;
> >>+	TEST_SEGMENT_SEL(GUEST_SEL_LDTR, "GUEST_SEL_LDTR", sel, sel_saved);
> >>+
> >>+	if (!(vmcs_read(GUEST_RFLAGS) & X86_EFLAGS_VM) &&
> >>+	    !(vmcs_read(CPU_SECONDARY) & CPU_URG)) {
> >Rather than react to the environment, these tests should configure every
> >relevant aspect and ignore the ones it can't change.  E.g. the unit tests
> >aren't going to randomly launch a vm86 guest.  Ditto for the unusuable bit,
> >it's unlikely to be set for most segments and would be something to test
> >explicitly.
> 
> 
> Just wanted to clarify on the "unusable bit" part of your comment. Do you
> mean each of the segment register checks from the SDM should have two tests,
> one with the "unusable bit" set and the other with that bit not set,
> irrespective of the checks being conditional on the setting of that bit ?

Sort of.  In an ideal world, kvm-unit-tests would verify correctness of KVM
for both unusable=1 and unusable=0.  But, the unusable=1 validation space is
enormous, i.e. there are a bazillion combinations of random garbage that can
be thrown into GUEST_*S_{SE,ARBYTE,BASE}.  So yeah, it could be as simple as
running the same test as unusable=0, but expecting VM-Entry to succeed.

That being said, I don't understand the motivation for these tests.  KVM
doesn't have any dedicated logic for checking guest segments, i.e. these
tests are validating hardware behavior, not KVM behavior.  The validation
resources thrown at hardware dwarf what kvm-unit-tests can do, i.e. the
odds of finding a silicon bug are tiny, and the odds of such a bug being
exploitable aginst L0 are downright miniscule.

  reply	other threads:[~2020-03-11 21:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 22:51 [PATCH] kvm-unit-test: nVMX: Test Selector and Base Address fields of Guest Segment registers Krish Sadhukhan
2020-03-10 22:51 ` [PATCH] kvm-unit-test: nVMX: Test Selector and Base Address fields of Guest Segment Registers on vmentry of nested guests Krish Sadhukhan
2020-03-11 15:05   ` Sean Christopherson
2020-03-11 15:19     ` Sean Christopherson
2020-03-11 20:38     ` Krish Sadhukhan
2020-03-11 21:46       ` Sean Christopherson [this message]
2020-03-11 21:53         ` Nadav Amit
2020-03-11 22:54           ` Liran Alon
2020-03-11 23:12             ` Sean Christopherson
2020-03-11 23:21               ` Nadav Amit
2020-03-11 23:25                 ` Sean Christopherson
2020-03-11 23:35                   ` Nadav Amit
2020-03-11 23:22               ` Liran Alon
2020-03-11 23:30                 ` Sean Christopherson
2020-03-10 23:51 ` [PATCH] kvm-unit-test: nVMX: Test Selector and Base Address fields of Guest Segment registers Jim Mattson
     [not found]   ` <20200311152459.GD21852@linux.intel.com>
2020-03-12 23:37     ` Krish Sadhukhan

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=20200311214657.GJ21852@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /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.