Re: [Xen-devel] Writable page tables questions

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/01/2015 17:17, Junji Zhi wrote:
> Hi,
>
> I'm Junji, a newbie in Xen and hoping I can contribute to the
> community one day. I have a few questions regarding the writable page
> tables, while reading The Definitive Guide to the Xen Hypervisor by
> David Chisnall:
>
> 1. Writable page tables is one Xen memory assist technique, applied to
> paravirtualized guests ONLY. HVM does not apply. Correct?
>
> 2. According to the book, when a guest wants to modify its page table,
> it triggers a trap into the hypervisor and it does a few steps:
>
> (1) it invalidates a PTE that points to the page containing the page
> table. Is my understanding correct?
>
> Q: What does "invalidate" really mean here? Does it mean simply
> flipping a bit in the PTE of the page table, or removing the PTE
> completely? Does it also need to invalidate the TLB entry?
>
> (2) then the control goes back to the guest and it can write/read the
> page table now.
>
> (3) The book's words pasted: "When an address referenced by the newly
> invalidated page directory entry is referenced (read or write), a page
> fault occurs. "
>
> Q: The description of step (3) is confusing. What does it mean by "an
> address referenced by the newly invalidated page directory entry is
> referenced"? Does it mean the case when the guest code is accessing an
> virtual address that needs to search the invalidated page table for
> translation?

I do not have the Chisnall book to hand at the moment, so cannot comment
as to the exact text in it.

However, looking at the code as it exists today,
XENFEAT_writable_page_tables (there is a typo in the ABI) is strictly
only offered to HVM guests, and not to PV guests.

PV guests must, under all circumstances, have their pagetables reachable
from any cr3 read-only.  Any ability to write to an active pagetable
without an audit from Xen would be a security issue, as a guest could
give itself access to frames which belonged to Xen or other guests.

Updating an individual PTE can be done by either writing directly to it,
in which case Xen will trap, emulate and audit the attempt, or use an
appropriate hypercall, which will be more efficient as no emulation is
required.  A PV guest is required to perform its own TLB management when
necessary (again, hypercall or trap and emulate).

Updating pagetables in general can either be done by updating each PTE
individually, or by constructing a new pagetable from scratch, pinning
it (via hypercall), which performs all the auditing at once, then
introducing it into the active set of pagetables.

An example might be:
1) Write all 512 entries into a regular page
2) Unmap the page (taking its refcount to 0, to permit a typechange)
3) Pinning the page as a specific type of pagetable (each level of
pagetables have a different type, for refcounting purposes)
4) PTE write or hypercall to introduce this new pagetable into the
active set.

The important points are that nothing can ever be changed in the active
set of pagetables without an audit by Xen, but the cost of the audit can
be amortised by constructing pagetables separately in a regular page first.

I hope this helps to clarify the situation.

~Andrew


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