This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Xen Guest Memory Isolation

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Xen Guest Memory Isolation
From: Ahmed Azab <amazab@xxxxxxxx>
Date: Tue, 14 Apr 2009 18:16:41 -0400
Delivery-date: Tue, 14 Apr 2009 15:18:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20090302)
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.

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

<Prev in Thread] Current Thread [Next in Thread>