linux-kernel - Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54ec213c-ef9f-23ed-4de8-4a1eeb50aca0@linux.intel.com>
Date:   Thu, 11 May 2017 11:21:25 +1200
From:   "Huang, Kai" <kai.huang@...ux.intel.com>
To:     Bandan Das <bsd@...hat.com>, Paolo Bonzini <pbonzini@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging



On 5/11/2017 4:00 AM, Bandan Das wrote:
> Paolo Bonzini <pbonzini@...hat.com> writes:
> ...
>>> Is the purpose of returning 1 to make upper layer code to inject PML
>>> full VMEXIt to L1 in nested_ept_inject_page_fault?
>>
>> Yes, it triggers a fault
>>>> +
>>>> +        gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) & ~0xFFFull;
>>>> +
>>>> +        page = nested_get_page(vcpu, vmcs12->pml_address);
>>>> +        if (!page)
>>>> +            return 0;
>>>
>>> If PML is enabled in L1, I think nested_get_page should never return a
>>> NULL PML page (unless L1 does something wrong)? Probably better to
>>> return 1 rather than 0, and handle error in nested_ept_inject_page_fault
>>> according to vmcs12->pml_address?
>>
>> This happens if the PML address is invalid (where on real hardware, the
>> write would just be "eaten") or MMIO (where we expect to diverge from
>
> Yes, that was my motivation. On real hardware, the hypervisor would still
> run except that the PML buffer is corrupt.

Right. Fine to me. :)

>
> Bandan
>
>> real hardware behavior).
>>
>>>> +
>>>> +        pml_address = kmap(page);
>>>> +        pml_address[vmcs12->guest_pml_index--] = gpa;
>>>
>>> This gpa is L2 guest's GPA. Do we also need to mark L1's GPA (which is
>>> related to L2 guest's GPA above) in to dirty-log? Or has this already
>>> been done?
>>
>> L1's PML contains L1 host physical addresses, i.e. L0 guest physical
>> addresses.  This GPA comes from vmcs02 and hence it is L0's GPA.

Do you mean pml_address? I was talking about gpa got from 
vmcs_read64(GUEST_PHYSICAL_ADDRESS). From hardware's point of view, PML 
always logs "GPA" into PML buffer so I was saying the gpa from 
vmcs_read64(GUEST_PHYSICAL_ADDRESS) should be L2 guest's PA. Anyway this 
is not important now. :)

>>
>> L0's HPA is marked by hardware through PML, as usual.  If L0 has EPT A/D
>> but not PML, it can still provide emulated PML to L1, but L0's HPA will
>> be marked as dirty via write protection.

Yes this is what I was thinking. For L0 PML takes care of L1 
hpyervisor's dirty page, while write protection takes care of dirty page 
from L2. No problem.

Thanks,
-Kai

>>
>> Paolo
>