[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 19.11.15 at 08:44, <feng.wu@xxxxxxxxx> wrote:

> 
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> Sent: Wednesday, November 18, 2015 6:11 PM
>> To: Wu, Feng <feng.wu@xxxxxxxxx>; Jan Beulich <JBeulich@xxxxxxxx>
>> Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; wei.liu2@xxxxxxxxxx;
>> ian.campbell@xxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
>> george.dunlap@xxxxxxxxxxxxx; ian.jackson@xxxxxxxxxxxxx; xen-
>> devel@xxxxxxxxxxxxx; Nakajima, Jun <jun.nakajima@xxxxxxxxx>; Han,
>> Huaitong <huaitong.han@xxxxxxxxx>; keir@xxxxxxx 
>> 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-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
>> >> bounces@xxxxxxxxxxxxx] On Behalf Of Jan Beulich
>> >> Sent: Tuesday, November 17, 2015 6:26 PM
>> >> To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> >> Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; wei.liu2@xxxxxxxxxx;
>> >> ian.campbell@xxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
>> >> george.dunlap@xxxxxxxxxxxxx; ian.jackson@xxxxxxxxxxxxx; xen-
>> >> devel@xxxxxxxxxxxxx; Nakajima, Jun <jun.nakajima@xxxxxxxxx>; Han,
>> >> Huaitong <huaitong.han@xxxxxxxxx>; keir@xxxxxxx 
>> >> Subject: Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory
>> >> protection-key support
>> >>
>> >>>>> On 16.11.15 at 18:45, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.