xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Kevin Tian <kevin.tian@intel.com>, Tim Deegan <tim@xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
Date: Tue, 14 Feb 2017 17:42:43 +0000	[thread overview]
Message-ID: <5fbed681-36bf-65d7-206a-d7438c20dad6@citrix.com> (raw)
In-Reply-To: <1486983604-21845-1-git-send-email-andrew.cooper3@citrix.com>

On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
> backpointer.
> 
> However, plenty of hardware has a physical address width less that 44 bits,
> and the code added in shadow_domain_init() is a straight assignment.  This
> causes gfn_bits to be increased beyond the physical address width on most
> Intel consumer hardware (typically a width of 39, which is the number reported
> to the guest via CPUID).
> 
> If the guest intentionally creates a PTE referencing a physical address
> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
> address.  However, the shadow code accepts the PTE, shadows it, and the
> virtual address works normally.
> 
> Introduce paging_max_paddr_bits() to calculate the largest guest physical
> address supportable by the paging infrastructure, and update
> recalculate_cpuid_policy() to take this into account when clamping the guests
> cpuid_policy to reality.  Remove gfn_bits and rework its users in terms of a
> guests maxphysaddr.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: George Dunlap <george.dunlap@eu.citrix.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>
> 
> v2:
>  * Introduce paging_max_paddr_bits() rather than moving paging logic into
>    recalculate_cpuid_policy().
>  * Rewrite half of the commit message.
> ---
>  xen/arch/x86/cpuid.c            |  7 +++----
>  xen/arch/x86/hvm/vmx/vvmx.c     |  2 +-
>  xen/arch/x86/mm/guest_walk.c    |  3 ++-
>  xen/arch/x86/mm/hap/hap.c       |  2 --
>  xen/arch/x86/mm/p2m.c           |  3 ++-
>  xen/arch/x86/mm/shadow/common.c | 10 ----------
>  xen/arch/x86/mm/shadow/multi.c  |  3 ++-
>  xen/include/asm-x86/domain.h    |  3 ---
>  xen/include/asm-x86/paging.h    | 16 ++++++++++++++++
>  9 files changed, 26 insertions(+), 23 deletions(-)
> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..3378f7a 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -6,6 +6,7 @@
>  #include <asm/hvm/nestedhvm.h>
>  #include <asm/hvm/svm/svm.h>
>  #include <asm/hvm/vmx/vmcs.h>
> +#include <asm/paging.h>
>  #include <asm/processor.h>
>  #include <asm/xstate.h>
>  
> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>  
>      cpuid_featureset_to_policy(fs, p);
>  
> -    p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>      p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
> -                                d->arch.paging.gfn_bits + PAGE_SHIFT);
> -    p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
> -                                (p->basic.pae || p->basic.pse36) ? 36 : 32);
> +                                paging_max_paddr_bits(d));
> +    p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>  
>      p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>  
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 9c61b5b..774a11f 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>      }
>  
>      if ( (gpa & ~PAGE_MASK) ||
> -         (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
> +         (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>      {
>          vmfail_invalid(regs);
>          return X86EMUL_OKAY;
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index a67fd5a..5ad8cf6 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>      /* If this guest has a restricted physical address space then the
>       * target GFN must fit within it. */
>      if ( !(rc & _PAGE_PRESENT)
> -         && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
> +         && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
> +         (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )

This pattern, of taking a gfn and shifting it by
(cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
several times; it seems like for both clarity and avoiding mistakes, it
would be better if it were put into a macro.

Everything else looks good to me.  (No opinion on the other questions
raised so far.)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-02-14 17:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08 12:36 [PATCH] x86/shadow: Correct the behaviour of a guests view of maxphysaddr Andrew Cooper
2017-02-08 14:12 ` Tim Deegan
2017-02-08 15:29   ` Andrew Cooper
2017-02-08 16:02     ` Tim Deegan
2017-02-13 11:00 ` [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr Andrew Cooper
2017-02-13 12:36   ` Jan Beulich
2017-02-14 16:04     ` Andrew Cooper
2017-02-14 16:46       ` Tim Deegan
2017-02-15  8:36       ` Jan Beulich
2017-02-14 17:42   ` George Dunlap [this message]
2017-02-14 17:45     ` Andrew Cooper
2017-02-14 17:49       ` George Dunlap
2017-02-14 17:56         ` Andrew Cooper
2017-02-15 16:02           ` George Dunlap

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=5fbed681-36bf-65d7-206a-d7438c20dad6@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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 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).