From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support Date: Wed, 18 Nov 2015 10:10:45 +0000 Message-ID: <564C4EA5.5030609@citrix.com> References: <1447669917-17939-1-git-send-email-huaitong.han@intel.com> <564A1652.70202@citrix.com> <564B0ED902000078000B5C8E@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" , Jan Beulich Cc: "Tian, Kevin" , "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "george.dunlap@eu.citrix.com" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , "Nakajima, Jun" , "Han, Huaitong" , "keir@xen.org" List-Id: xen-devel@lists.xenproject.org On 18/11/15 09:12, Wu, Feng wrote: > >> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >> bounces@lists.xen.org] On Behalf Of Jan Beulich >> Sent: Tuesday, November 17, 2015 6:26 PM >> To: Andrew Cooper >> Cc: Tian, Kevin ; wei.liu2@citrix.com; >> ian.campbell@citrix.com; stefano.stabellini@eu.citrix.com; >> george.dunlap@eu.citrix.com; ian.jackson@eu.citrix.com; xen- >> devel@lists.xen.org; Nakajima, Jun ; Han, >> Huaitong ; keir@xen.org >> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory >> protection-key support >> >>>>> On 16.11.15 at 18:45, wrote: >>> Furthermore, it is unclear (given the unwritten ABI) whether it is even >>> safe to move _PAGE_GNTTAB out of the way, as this is visible to a PV guest. >> It seems pretty clear to me that this would be unsafe: It being >> part of L1_DISALLOW_MASK, if it moved and a guest used the >> bit for its own purposes, the guest would break. I guess we'll >> need an ELF note by which the guest can advertise which of the >> available bits it doesn't care about itself. > Actually, we don't expose this feature to PV guest, we only expose it > to HVM. In that case, is there still issues like you discussed above? You have turned on CR4.PKE, and _PAGE_GNTTAB is bit 62 in a PTE. Futhermore, you don't prevent/audit a PV guest's use of the PK bits. This makes it usable by PV guests, even if the feature isn't advertised. ~Andrew