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

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

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.

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

Does this stand despite the OSPKE issue?


Xen-devel mailing list



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