From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: kvm list <kvm@vger.kernel.org>,
Liran Alon <liran.alon@oracle.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Dan Cross <dcross@google.com>, Peter Shier <pshier@google.com>
Subject: Re: [PATCH v3] KVM: nVMX: Don't leak L1 MMIO regions to L2
Date: Mon, 14 Oct 2019 12:15:22 -0700 [thread overview]
Message-ID: <20191014191522.GG22962@linux.intel.com> (raw)
In-Reply-To: <CALMp9eS_fYjyTDG75316cdyCp6NRHAHmN2J+sTf9uxvUfiEsQA@mail.gmail.com>
On Mon, Oct 14, 2019 at 11:50:37AM -0700, Jim Mattson wrote:
> On Mon, Oct 14, 2019 at 10:59 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> > > @@ -2947,19 +2947,18 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
> > > vmx->nested.apic_access_page = NULL;
> > > }
> > > page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->apic_access_addr);
> > > - /*
> > > - * If translation failed, no matter: This feature asks
> > > - * to exit when accessing the given address, and if it
> > > - * can never be accessed, this feature won't do
> > > - * anything anyway.
> > > - */
> > > if (!is_error_page(page)) {
> > > vmx->nested.apic_access_page = page;
> > > hpa = page_to_phys(vmx->nested.apic_access_page);
> > > vmcs_write64(APIC_ACCESS_ADDR, hpa);
> > > } else {
> > > - secondary_exec_controls_clearbit(vmx,
> > > - SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES);
> > > + pr_debug_ratelimited("%s: non-cacheable APIC-access address in vmcs12\n",
> > > + __func__);
> >
> > Hmm, "non-cacheable" is confusing, especially in the context of the APIC,
> > which needs to be mapped "uncacheable". Maybe just "invalid"?
>
> "Invalid" is not correct. L1 MMIO addresses are valid; they're just
> not cacheable. Perhaps:
>
> "vmcs12 APIC-access address references a page not backed by a memslot in L1"?
Hmm, technically is_error_page() isn't limited to a non-existent memslot,
any GFN that doesn't lead to a 'struct page' will trigger is_error_page().
Maybe just spit out what literally went wrong? E.g something like
pr_debug_ratelimited("%s: no backing 'struct page' for APIC-access address in vmcs12\n"
> > > + vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> > > + vcpu->run->internal.suberror =
> > > + KVM_INTERNAL_ERROR_EMULATION;
> > > + vcpu->run->internal.ndata = 0;
> > > + return false;
> > > }
> > > }
> > >
> > > @@ -3004,6 +3003,7 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
> > > exec_controls_setbit(vmx, CPU_BASED_USE_MSR_BITMAPS);
> > > else
> > > exec_controls_clearbit(vmx, CPU_BASED_USE_MSR_BITMAPS);
> > > + return true;
> > > }
> > >
> > > /*
> > > @@ -3042,13 +3042,15 @@ static void load_vmcs12_host_state(struct kvm_vcpu *vcpu,
> > > /*
> > > * If from_vmentry is false, this is being called from state restore (either RSM
> > > * or KVM_SET_NESTED_STATE). Otherwise it's called from vmlaunch/vmresume.
> > > -+ *
> > > -+ * Returns:
> > > -+ * 0 - success, i.e. proceed with actual VMEnter
> > > -+ * 1 - consistency check VMExit
> > > -+ * -1 - consistency check VMFail
> > > + *
> > > + * Returns:
> > > + * ENTER_VMX_SUCCESS: Successfully entered VMX non-root mode
> >
> > "Enter VMX" usually refers to VMXON, e.g. the title of VMXON in the SDM is
> > "Enter VMX Operation".
> >
> > Maybe NVMX_ENTER_NON_ROOT_?
>
> How about NESTED_VMX_ENTER_NON_ROOT_MODE_STATUS_?
>
> > > + * ENTER_VMX_VMFAIL: Consistency check VMFail
> > > + * ENTER_VMX_VMEXIT: Consistency check VMExit
> > > + * ENTER_VMX_ERROR: KVM internal error
> >
> > Probably need to more explicit than VMX_ERROR, e.g. all of the VM-Fail
> > defines are prefixed with VMXERR_##.
> >
> > May ENTER_VMX_KVM_ERROR? (Or NVMX_ENTER_NON_ROOT_KVM_ERROR).
>
> NESTED_VMX_ENTER_NON_ROOT_MODE_STATUS_KVM_INTERNAL_ERROR?
I can't tell if you're making fun of me for being pedantic about "Enter VMX",
or if you really want to have a 57 character enum. :-)
NESTED_VMENTER_?
next prev parent reply other threads:[~2019-10-14 19:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 23:28 [PATCH v3] KVM: nVMX: Don't leak L1 MMIO regions to L2 Jim Mattson
2019-10-14 17:59 ` Sean Christopherson
2019-10-14 18:50 ` Jim Mattson
2019-10-14 19:15 ` Sean Christopherson [this message]
2019-10-14 19:37 ` Jim Mattson
2019-10-14 19:52 ` Sean Christopherson
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=20191014191522.GG22962@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=dcross@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=pbonzini@redhat.com \
--cc=pshier@google.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.