linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Mohammed Gamal <mgamal@redhat.com>, kvm@vger.kernel.org
Cc: sean.j.christopherson@intel.com, vkuznets@redhat.com,
	wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] KVM: x86: mmu: Add guest physical address check in translate_gpa()
Date: Thu, 27 Feb 2020 19:00:33 +0100	[thread overview]
Message-ID: <f81e0503-bc35-d682-4440-68b81c10784f@redhat.com> (raw)
In-Reply-To: <20200227172306.21426-6-mgamal@redhat.com>

On 27/02/20 18:23, Mohammed Gamal wrote:
> In case of running a guest with 4-level page tables on a 5-level page
> table host, it might happen that a guest might have a physical address
> with reserved bits set, but the host won't see that and trap it.
> 
> Hence, we need to check page faults' physical addresses against the guest's
> maximum physical memory and if it's exceeded, we need to add
> the PFERR_RSVD_MASK bits to the PF's error code.

You can just set it to PFERR_RSVD_MASK | PFERR_PRESENT_MASK (no need to
use an "|") and return UNMAPPED_GBA.  But I would have thought that this
is not needed and the

                if (unlikely(FNAME(is_rsvd_bits_set)(mmu, pte, walker->level))) {
                        errcode = PFERR_RSVD_MASK | PFERR_PRESENT_MASK;
                        goto error;
                }

code would have catch the reserved bits.

> Also make sure the error code isn't overwritten by the page table walker.

Returning UNMAPPED_GVA would remove that as well.

I'm not sure this patch is enough however.  For a usermode access with
"!pte.u pte.40" for example you should be getting:

- a #PF with PRESENT|USER error code on a machine with physical address
width >=41; in this case you don't get an EPT violation or misconfig.

- a #PF with RSVD error code on a machine with physical address with <41.

You can enable verbose mode in access.c to see if this case is being generated,
and if so debug it.

The solution for this would be to trap page faults and do a page table
walk (with vcpu->arch.walk_mmu->gva_to_gpa) to find the correct error
code.

Paolo


  reply	other threads:[~2020-02-27 18:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 17:23 [PATCH 0/5] KVM: Support guest MAXPHYADDR < host MAXPHYADDR Mohammed Gamal
2020-02-27 17:23 ` [PATCH 1/5] KVM: x86: Add function to inject guest page fault with reserved bits set Mohammed Gamal
2020-02-27 19:30   ` Ben Gardon
2020-02-28 22:29   ` Sean Christopherson
2020-02-27 17:23 ` [PATCH 2/5] KVM: VMX: Add guest physical address check in EPT violation and misconfig Mohammed Gamal
2020-02-27 17:55   ` Jim Mattson
2020-02-28 22:36     ` Sean Christopherson
2020-02-27 17:23 ` [PATCH 3/5] KVM: SVM: Add guest physical address check in NPF interception Mohammed Gamal
2020-02-27 17:23 ` [PATCH 4/5] KVM: x86: mmu: Move translate_gpa() to mmu.c Mohammed Gamal
2020-02-27 17:23 ` [PATCH 5/5] KVM: x86: mmu: Add guest physical address check in translate_gpa() Mohammed Gamal
2020-02-27 18:00   ` Paolo Bonzini [this message]
2020-02-28 22:26     ` Sean Christopherson
2020-02-27 17:58 ` [PATCH 0/5] KVM: Support guest MAXPHYADDR < host MAXPHYADDR Jim Mattson

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=f81e0503-bc35-d682-4440-68b81c10784f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgamal@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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 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).