Nested EPT Write Protection

Nested EPT Write Protection

[Hu Yaohui]

Hi All,
In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
the L1 guest writes to the guest EPT(EPT12). How can the shadow
EPT(EPT02) be modified according?

Thanks,
Yaohui

Re: Nested EPT Write Protection

[Paolo Bonzini]

On 19/06/2015 03:52, Hu Yaohui wrote:
> Hi All,
> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
> the L1 guest writes to the guest EPT(EPT12). How can the shadow
> EPT(EPT02) be modified according?

Because the EPT02 is write protected, writes to the EPT12 will trap to
the hypervisor.  The hypervisor will execute the write instruction
before reentering the guest and invalidate the modified parts of the
EPT02.  When the invalidated part of the EPT02 is accessed, the
hypervisor will rebuild it according to the EPT12 and the KVM memslots.

Paolo

Re: Nested EPT Write Protection

[Hu Yaohui]

Hi Paolo,
Thanks a lot!

On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 19/06/2015 03:52, Hu Yaohui wrote:
>> Hi All,
>> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
>> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
>> the L1 guest writes to the guest EPT(EPT12). How can the shadow
>> EPT(EPT02) be modified according?
>
> Because the EPT02 is write protected, writes to the EPT12 will trap to
> the hypervisor.  The hypervisor will execute the write instruction
> before reentering the guest and invalidate the modified parts of the
> EPT02.  When the invalidated part of the EPT02 is accessed, the
> hypervisor will rebuild it according to the EPT12 and the KVM memslots.
>
Do you mean EPT12 is write protected instead of EPT02?
According to my understanding, EPT12 will be write protected by marking the
page table entry of EPT01 as readonly or marking the host page table
entry as readonly.
Could you please be more specific the code path which makes the
corresponding page table entry as write protected?

Thanks,
Yaohui
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: Nested EPT Write Protection

[Paolo Bonzini]

On 19/06/2015 14:44, Hu Yaohui wrote:
> Hi Paolo,
> Thanks a lot!
> 
> On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>
>> On 19/06/2015 03:52, Hu Yaohui wrote:
>>> Hi All,
>>> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
>>> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
>>> the L1 guest writes to the guest EPT(EPT12). How can the shadow
>>> EPT(EPT02) be modified according?
>>
>> Because the EPT02 is write protected, writes to the EPT12 will trap to
>> the hypervisor.  The hypervisor will execute the write instruction
>> before reentering the guest and invalidate the modified parts of the
>> EPT02.  When the invalidated part of the EPT02 is accessed, the
>> hypervisor will rebuild it according to the EPT12 and the KVM memslots.
>>
> Do you mean EPT12 is write protected instead of EPT02?

Yes, sorry.

> According to my understanding, EPT12 will be write protected by marking the
> page table entry of EPT01 as readonly or marking the host page table
> entry as readonly.
> Could you please be more specific the code path which makes the
> corresponding page table entry as write protected?

Look at set_spte's call to mmu_need_write_protect.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: Nested EPT Write Protection

[Hu Yaohui]

Thanks a lot! It's much straightforward to me right now.

One more thing, for the standard guest VM which uses EPT, What's the
usage of "gfn" field in the "struct kvm_mmu_page"?  Since it uses EPT,
a single shadow page should has no relation with any of the guest
physical page, right? According to the source code, each allocated
shadow page "struct kvm_mmu_page" got it's gfn field filled.

Thanks,
Yaohui

On Fri, Jun 19, 2015 at 11:23 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 19/06/2015 14:44, Hu Yaohui wrote:
>> Hi Paolo,
>> Thanks a lot!
>>
>> On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>
>>>
>>> On 19/06/2015 03:52, Hu Yaohui wrote:
>>>> Hi All,
>>>> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the
>>>> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If
>>>> the L1 guest writes to the guest EPT(EPT12). How can the shadow
>>>> EPT(EPT02) be modified according?
>>>
>>> Because the EPT02 is write protected, writes to the EPT12 will trap to
>>> the hypervisor.  The hypervisor will execute the write instruction
>>> before reentering the guest and invalidate the modified parts of the
>>> EPT02.  When the invalidated part of the EPT02 is accessed, the
>>> hypervisor will rebuild it according to the EPT12 and the KVM memslots.
>>>
>> Do you mean EPT12 is write protected instead of EPT02?
>
> Yes, sorry.
>
>> According to my understanding, EPT12 will be write protected by marking the
>> page table entry of EPT01 as readonly or marking the host page table
>> entry as readonly.
>> Could you please be more specific the code path which makes the
>> corresponding page table entry as write protected?
>
> Look at set_spte's call to mmu_need_write_protect.
>
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: Nested EPT Write Protection

[Paolo Bonzini]

On 19/06/2015 20:57, Hu Yaohui wrote:
> One more thing, for the standard guest VM which uses EPT, What's the
> usage of "gfn" field in the "struct kvm_mmu_page"?  Since it uses EPT,
> a single shadow page should has no relation with any of the guest
> physical page, right?

The gfn is the same value that you can find in bits 12 to MAXPHYADDR-1
of the EPT page table entry.

Paolo

> According to the source code, each allocated
> shadow page "struct kvm_mmu_page" got it's gfn field filled.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in

Re: Nested EPT Write Protection

[Paolo Bonzini]

On 22/06/2015 15:28, Hu Yaohui wrote:
> 
> */2504             pseudo_gfn = base_addr >> PAGE_SHIFT;
> 2505             sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
> 2506                           iterator.level - 1,
> 2507                           1, ACC_ALL, iterator.sptep);/*
> 2508             if (!sp) {
> 2509                 pgprintk("nonpaging_map: ENOMEM\n");
> 2510                 kvm_release_pfn_clean(pfn);
> 2511                 return -ENOMEM;
> 2512             }
>                                    .........
> 
> </code>
> it will get a pseudo_gfn to allocate a kvm_mmu_page. What if a
> pseudo_gfn itself causes a tdp_page_fault?
> Will it make the corresponding EPT page table entry marked as readonly also?

If tdp_page_fault is used (meaning non-nested KVM: nested KVM uses
ept_page_fault instead), sp->unsync is always true:

	/* in kvm_mmu_get_page - __direct_map passes direct == true */
        if (!direct) {
                if (rmap_write_protect(vcpu, gfn))
                        kvm_flush_remote_tlbs(vcpu->kvm);
                if (level > PT_PAGE_TABLE_LEVEL && need_sync)
                        kvm_sync_pages(vcpu, gfn);

                account_shadowed(vcpu->kvm, sp);
        }

so mmu_need_write_protect always returns false.

Note that higher in kvm_mmu_get_page there is another conditional:

                if (!need_sync && sp->unsync)
                        need_sync = true;

but it only applies to the !direct case.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in