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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.17 at 10:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 31/05/2017 08:56, Jan Beulich wrote:
>>>>> On 31.05.17 at 09:44, <andrew.cooper3@xxxxxxxxxx> 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.
>> Shouldn't we correct this (independent of the patch here)?
> 
> No, I don't think so.  That would involve the generic cpuid code looking
> at GUEST_CR4 and making decisions contrary to what is described in the
> manuals.
> 
> Besides, it very definitely should be visible in a read of CR4 (because
> the guest did really set it), which means OSPKE should be visible in CPUID.

Oh, then I misunderstood your earlier reply, taking it that we
wrongly show the flag as set to the guest.

Jan


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