xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Han, Huaitong" <huaitong.han@intel.com>
To: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode"
Date: Wed, 31 May 2017 07:09:31 +0000	[thread overview]
Message-ID: <1496214571.3661.24.camel@intel.com> (raw)
In-Reply-To: <1495818213-345-2-git-send-email-andrew.cooper3@citrix.com>

On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote:
> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
> 
> When determining Access Rights, Protection Keys only take effect when CR4.PKE
> it set, and 4-level paging is active.  All other circumstances (notibly, 32bit
> PAE paging) skip the Protection Key control mechanism.
> 
> Therefore, we do not need to clear CR4.PKE behind the back of a guest which is
> not using paging, as such a guest is necesserily running with EFER.LME
> disabled.

Yes, if EFER.LME = 0, Protection Keys would take no effect too, so it
isn't necessary to clear CR4.PKE in non-paging mode.

> 
> The {RD,WR}PKRU instructions are specified as being legal for use in any
> operating mode, but only if CR4.PKE is set.  By clearing CR4.PKE behind the
> back of an unpaged guest, these instructions yield #UD despite the guest
> seeing PKE set if it reads CR4, and OSPKE being visible in CPUID.
If CR4.PKE is cleared, OSPKE would be invisible at the same time. When
guest does set CR4_PKE in non-paging mode, then CR4_PKE would be cleared
in vmcs loading, so, OSPKE should be always invisible, and #UD should
not be yielded too.

 
Reviewed-by: Huaitong Han <huaitong.han@intel.com>

> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>
> CC: Huaitong Han <huaitong.han@intel.com>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index c8ef18a..58552c3 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1673,13 +1673,12 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr)
>          if ( !hvm_paging_enabled(v) )
>          {
>              /*
> -             * SMEP/SMAP/PKU is disabled if CPU is in non-paging mode in
> -             * hardware. However Xen always uses paging mode to emulate guest
> -             * non-paging mode. To emulate this behavior, SMEP/SMAP/PKU needs
> -             * to be manually disabled when guest VCPU is in non-paging mode.
> +             * SMEP/SMAP is disabled if CPU is in non-paging mode in hardware.
> +             * However Xen always uses paging mode to emulate guest non-paging
> +             * mode. To emulate this behavior, SMEP/SMAP needs to be manually
> +             * disabled when guest VCPU is in non-paging mode.
>               */
> -            v->arch.hvm_vcpu.hw_cr[4] &=
> -                ~(X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_PKE);
> +            v->arch.hvm_vcpu.hw_cr[4] &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
>          }
>          __vmwrite(GUEST_CR4, v->arch.hvm_vcpu.hw_cr[4]);
>          break;

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

  parent reply	other threads:[~2017-05-31  7:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 17:03 [PATCH RFC for-4.9 0/2] x86/pagewalk: Further bugfixes to pagetable walking Andrew Cooper
2017-05-26 17:03 ` [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode" Andrew Cooper
2017-05-29  8:48   ` Jan Beulich
2017-05-31  7:09   ` Han, Huaitong [this message]
2017-05-31  7:44     ` Andrew Cooper
2017-05-31  7:56       ` Jan Beulich
2017-05-31  8:06         ` Andrew Cooper
2017-05-31  8:12           ` Jan Beulich
2017-05-31  8:14       ` Han, Huaitong
2017-06-01  2:15         ` Tian, Kevin
2017-05-26 17:03 ` [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches Andrew Cooper
2017-05-29  8:58   ` Jan Beulich
2017-05-29  9:03     ` Andrew Cooper
2017-05-29  9:15       ` Jan Beulich
2017-06-01 10:19         ` Andrew Cooper
2017-06-01 10:51           ` Jan Beulich
2017-06-01 11:22             ` Andrew Cooper
2017-06-01 12:06               ` Jan Beulich
2017-06-01 17:55 ` [PATCH RFC for-4.9 0/2] x86/pagewalk: Further bugfixes to pagetable walking Julien Grall
2017-06-01 17:57   ` Andrew Cooper
2017-06-01 18:00     ` Julien Grall

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=1496214571.3661.24.camel@intel.com \
    --to=huaitong.han@intel.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --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).