[Xen-devel] Xen Guest Memory Isolation
I have been inspecting Xen's security properties for a while and I have
some question regarding Guest page tables Isolation.
In para-virtualized guests. My understanding is (Please correct me if I
am wrong) that Xen achieves the isolation through (1) making all page
tables non-writable so that the guest have to ask Xen to do the update
through hypercalls and (2) having Xen validation each page-table update
to make sure domain X cannot access domain Y's memory.
Now by looking inside the code, I cannot see where does this happen. I
took a thorough look at the do_mmu_update hypercall and I observed that
the function extracts the new page table entry value directly from the
input parameter "req.val". Afterwards, it calls the function
mod_lX_entry() where X refers to the page table level.. These functions
in turn calls the macro Update_entry which calls the function
Update_intpte which probably ends up calling __copy_to_user or
compxchg_user directly to update the page table entry. As far as I
understand, all the observed path does not include any security checking.
MY QUESTIONS ARE:
1-Does Xen check that the passed value refers to a physical page that
really belongs to the calling domain? If yes, where is the code piece
that does that? If no, then what guarantees that the guest wont map a
page belonging to another guest?
2-If the guest is updating a higher level page table (l2 for example)
then the entry point to a lower level page table. Does Xen check that
the new cannot be rewritten by the guest? again where is the code or
what is the security guarantee?
3-Does Xen keep track of all page tables of a certain guest or it just
relies on the type_info value stored in the page data structure?
4-How does then guarantee that upon process switching the new cr3 value
will point to a page table that is protected by Xen?
One final thing. Can I force all guests (including para-virtualized ones
)to use shadow page tables?
Xen-devel mailing list