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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

This corner case (along with others) will soon be regression tested in
the (newly-introduced) 0-level paging pagetable-emulation XTF test,
which I put together after stumbling blindly into this particular #UD
while investigating a different issue.

~Andrew

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