Re: [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode"

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 08:14:31 +0000	[thread overview]
Message-ID: <1496218471.3661.29.camel@intel.com> (raw)
In-Reply-To: <cd35d55a-08ff-5162-1ff2-7a0744277021@citrix.com>

On Wed, 2017-05-31 at 08:44 +0100, Andrew Cooper wrote:
> On 31/05/2017 08:09, Han, Huaitong wrote:
> > 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.
> 
> Remember that for HVM guests, Xen calculates OSPKE in software; it never
> comes from hardware, as CPUID is an automatic VMEXIT.
> 
> The CPUID code uses the same source of information as a read from cr4,
> so comes to the conclusion that OSPKE should be visible.
> 
> Therefore, when the guest looks at CPUID, it sees OSPKE set even though
> hardware would come to the opposite conclusion.

Yes, I get the reason: the hw_cr4 is updated, but the guest_cr4 is not
updated, so the OSPKE is visible.

> 
> > Reviewed-by: Huaitong Han <huaitong.han@intel.com>
> 
> Does this stand despite the OSPKE issue?
Yes, I have no comments now.

> 
> ~Andrew

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