[Xen-devel] Xen Guest Memory Isolation

[Ahmed Azab <amazab@xxxxxxxx>]

Hi All,

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?
Thanks,
Ahmed







_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel