Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-19 Thread Jan Beulich 
>>> On 19.11.15 at 08:44, <feng...@intel.com> wrote:

> 
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, November 18, 2015 6:11 PM
>> To: Wu, Feng <feng...@intel.com>; Jan Beulich <jbeul...@suse.com>
>> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
>> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
>> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
>> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
>> Huaitong <huaitong@intel.com>; k...@xen.org 
>> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
>> protection-key support
>> 
>> On 18/11/15 09:12, Wu, Feng wrote:
>> >
>> >> -Original Message-
>> >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> >> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> >> Sent: Tuesday, November 17, 2015 6:26 PM
>> >> To: Andrew Cooper <andrew.coop...@citrix.com>
>> >> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
>> >> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
>> >> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
>> >> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
>> >> Huaitong <huaitong@intel.com>; k...@xen.org 
>> >> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
>> >> protection-key support
>> >>
>> >>>>> On 16.11.15 at 18:45, <andrew.coop...@citrix.com> 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.
> 
> Oh, yes, actually, we shouldn't turn on CR4.PKE for Xen, since we don't
> actually enable it for Xen itself (No such usage model).
> 
>> Futhermore, you don't prevent/audit a PV guest's use of the PK bits.
> 
> I think the guest (HVM or PV) should use the PK bits only when Pkey
> is enabled (CR4.PKE set) by the kernel, Xen cannot control it, right?

Correct, but this is connected to the earlier item. I.e. if only you make
sure Xen and PV guests get run with CR4.PKE always clear, then no
extra auditing will be necessary.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-19 Thread Wu, Feng 


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, November 19, 2015 4:44 PM
> To: Wu, Feng <feng...@intel.com>
> Cc: Andrew Cooper <andrew.coop...@citrix.com>; ian.campb...@citrix.com;
> wei.l...@citrix.com; george.dun...@eu.citrix.com;
> ian.jack...@eu.citrix.com; stefano.stabell...@eu.citrix.com; Han, Huaitong
> <huaitong@intel.com>; Nakajima, Jun <jun.nakaj...@intel.com>; Tian,
> Kevin <kevin.t...@intel.com>; xen-devel@lists.xen.org; k...@xen.org
> Subject: RE: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
> protection-key support
> 
> >>> On 19.11.15 at 08:44, <feng...@intel.com> wrote:
> 
> >
> Correct, but this is connected to the earlier item. I.e. if only you make
> sure Xen and PV guests get run with CR4.PKE always clear, then no
> extra auditing will be necessary.

Yes, I think we will make it clear. We only expose this to HVM. And for
Xen and PV, the CR4.PKE should be zero.

Thanks,
Feng

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-18 Thread Andrew Cooper 
On 18/11/15 09:12, Wu, Feng wrote:
>
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: Tuesday, November 17, 2015 6:26 PM
>> To: Andrew Cooper <andrew.coop...@citrix.com>
>> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
>> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
>> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
>> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
>> Huaitong <huaitong....@intel.com>; k...@xen.org
>> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
>> protection-key support
>>
>>>>> On 16.11.15 at 18:45, <andrew.coop...@citrix.com> 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

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-18 Thread Wu, Feng 


> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, November 17, 2015 6:26 PM
> To: Andrew Cooper <andrew.coop...@citrix.com>
> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
> Huaitong <huaitong@intel.com>; k...@xen.org
> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
> protection-key support
> 
> >>> On 16.11.15 at 18:45, <andrew.coop...@citrix.com> 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?

Thanks,
Feng

> 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-18 Thread Wu, Feng 


> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 18, 2015 6:11 PM
> To: Wu, Feng <feng...@intel.com>; Jan Beulich <jbeul...@suse.com>
> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
> Huaitong <huaitong....@intel.com>; k...@xen.org
> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
> protection-key support
> 
> On 18/11/15 09:12, Wu, Feng wrote:
> >
> >> -Original Message-
> >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> >> boun...@lists.xen.org] On Behalf Of Jan Beulich
> >> Sent: Tuesday, November 17, 2015 6:26 PM
> >> To: Andrew Cooper <andrew.coop...@citrix.com>
> >> Cc: Tian, Kevin <kevin.t...@intel.com>; wei.l...@citrix.com;
> >> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
> >> george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
> >> de...@lists.xen.org; Nakajima, Jun <jun.nakaj...@intel.com>; Han,
> >> Huaitong <huaitong@intel.com>; k...@xen.org
> >> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
> >> protection-key support
> >>
> >>>>> On 16.11.15 at 18:45, <andrew.coop...@citrix.com> 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.

Oh, yes, actually, we shouldn't turn on CR4.PKE for Xen, since we don't
actually enable it for Xen itself (No such usage model).

> Futhermore, you don't prevent/audit a PV guest's use of the PK bits.

I think the guest (HVM or PV) should use the PK bits only when Pkey
is enabled (CR4.PKE set) by the kernel, Xen cannot control it, right?

Thanks,
Feng

> 
> This makes it usable by PV guests, even if the feature isn't advertised.
> 
> ~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-17 Thread Jan Beulich 
>>> On 17.11.15 at 17:24,  wrote:
> On 17/11/15 10:26, Jan Beulich wrote:
> 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.
> 
> Well - it depends whether any of these bits actually get used.
> 
> If none actually do get used, we would be better to retro-fit a real ABI
> in place, without requiring all new guests to opt-in to get new features.

And how exactly do you propose we check _all_ existing kernels?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-17 Thread Andrew Cooper 
On 17/11/15 10:26, Jan Beulich wrote:
 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.

Well - it depends whether any of these bits actually get used.

If none actually do get used, we would be better to retro-fit a real ABI
in place, without requiring all new guests to opt-in to get new features.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-17 Thread Jan Beulich 
>>> 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.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

2015-11-16 Thread Huaitong Han 
The protection-key feature provides an additional mechanism by which IA-32e
paging controls access to usermode addresses.

Hardware support for protection keys for user pages is enumerated with CPUID
feature flag CPUID.7.0.ECX[3]:PKU. Software support is CPUID.7.0.ECX[4]:OSPKE
with the setting of CR4.PKE(bit 22).

When CR4.PKE = 1, every linear address is associated with the 4-bit protection
key located in bits 62:59 of the paging-structure entry that mapped the page
containing the linear address. The PKRU register determines, for each
protection key, whether user-mode addresses with that protection key may be
read or written.

The PKRU register (protection key rights for user pages) is a 32-bit register
with the following format: for each i (0 ≤ i ≤ 15), PKRU[2i] is the
access-disable bit for protection key i (ADi); PKRU[2i+1] is the write-disable
bit for protection key i (WDi).

Software can use the RDPKRU and WRPKRU instructions with ECX = 0 to read and
write PKRU. In addition, the PKRU register is XSAVE-managed state and can thus
be read and written by instructions in the XSAVE feature set.

PFEC.PK (bit 5) is defined as protection key violations.

The specification of Protection Keys can be found at SDM (4.6.2, volume 3)
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf.

Huaitong Han (10):
  x86/hvm: pkeys, add pkeys support for cpuid handling
  x86/hvm: pkeys, add pku support for x86_capability
  x86/hvm: pkeys, add the flag to enable Memory Protection Keys
  x86/hvm: pkeys, add pkeys support when setting CR4
  x86/hvm: pkeys, disable pkeys for guests in non-paging mode
  x86/hvm: pkeys, add functions to get pkeys value from PTE
  x86/hvm: pkeys, add functions to support PKRU access/write
  x86/hvm: pkeys, add pkeys support for do_page_fault
  x86/hvm: pkeys, add pkeys support for guest_walk_tables
  x86/hvm: pkeys, add xstate support for pkeys

 docs/misc/xen-command-line.markdown |  7 +
 tools/libxc/xc_cpufeature.h |  2 ++
 tools/libxc/xc_cpuid_x86.c  |  6 ++--
 xen/arch/x86/cpu/common.c   |  5 ++--
 xen/arch/x86/hvm/hvm.c  | 11 ++-
 xen/arch/x86/hvm/vmx/vmx.c  | 11 +++
 xen/arch/x86/mm/guest_walk.c| 57 -
 xen/arch/x86/setup.c|  9 ++
 xen/arch/x86/traps.c| 47 +-
 xen/include/asm-x86/cpufeature.h|  7 -
 xen/include/asm-x86/guest_pt.h  | 11 +++
 xen/include/asm-x86/hvm/hvm.h   |  2 ++
 xen/include/asm-x86/page.h  |  7 +
 xen/include/asm-x86/processor.h | 53 +-
 xen/include/asm-x86/x86_64/page.h   | 14 +
 xen/include/asm-x86/xstate.h|  3 +-
 16 files changed, 225 insertions(+), 27 deletions(-)

-- 
2.4.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel