lkml.org 
[lkml]   [2016]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/4] KVM: MMU: fix permission_fault()
From
Date


On 03/30/2016 02:39 PM, Xiao Guangrong wrote:
>
>
> On 03/30/2016 02:36 PM, Paolo Bonzini wrote:
>>
>>
>> On 30/03/2016 03:56, Xiao Guangrong wrote:
>>>> x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
>>>> is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can you use it
>>>> (with ept=1 of course) to check what the processor is doing?
>>>
>>> Sure.
>>>
>>> And ept=1 is hard to trigger MMU issue, i am enabling PKEY on shadow
>>> MMU, let's see what will happen. ;)
>>
>> No, don't do that!
>>
>> ept=1 lets you test what the processor does. It means you cannot test
>> permission_fault(), but what we want here is just reverse engineering
>> the microcode. ept=1 lets you do exactly that.
>
> Yes, i got this point. Huaitong will do the test once the machine gets
> free.

I tested it and it is failed:

test pte.p pte.user pde.p pde.user pde.a pde.pse pkru.wd pkey=1 user write efer.nx cr4.pke: FAIL:
error code 27 expected 7
Dump mapping: address: 0x123400000000
------L4: 2ebe007
------L3: 2ebf007
------L2: 8000000020000a5

So PFEC.PKEY is set even if the ordinary check failed (caused by pde.rw = 0), the kvm code is
right. :)

\
 
 \ /
  Last update: 2016-04-06 05:41    [W:0.044 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site