WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

Re: [Xense-devel] Xen memory management

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xense-devel] Xen memory management
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Thu, 16 Feb 2006 11:11:50 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Feb 2006 16:24:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200602161427.37036.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

Thank you for bringing this topic up Myong. Thanks Mark for explaining the M2P mapping.

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/16/2006 09:27:36 AM:

> > Xen interface manual describes the following:
> > "Xen maintains a globally readable machine-to-physical table which
> > records the mapping from machine page frames to pseudo-physical ones."
> ...
> It's mapped into a domain's address space.  (nb. this is x86 specific).  I
> can't remember where it's mapped, though...  Anyhow, the overhead of a
> hypercall isn't necessary to read it, it's just a single memory access.
>
> The advantage here is that a domain can map a machine address back into a
> guest physical address by simply doing a table lookup.  This also means it
> can see the M2P mappings for all the other domains,

...
> but this doesn't really
> leak any information since it still can't see the memory contents of other

> domains.

The sentence above seems optimistic. To determine how much a domain can leak through this shared table is an interesting problem.
I have two questions related to this problem:

a) How easily can a domain affect its own M2P mapping?
   --> this gives a first estimate about how easily a  domain can modulate information onto the mapping,
        which can be observed by other domains looking at this mapping


b) Can this global mapping be converted to a per-domain mapping so that a domain can only access its own M2P mappings?
   (Is there any reason why one domain would need to see another domain's mapping?)

Note: there are non-Xen specific implicit/covert/illegal channels based on shared HW/SW resources. While this is not a Xen-specific problem, Xen as an open-source VMM offers a great foundation for researchers to apply existing and cooperatively develop new covert channel analysis technology and tools. Finding covert channels is one thing, estimating their real channel bandwidth is as important.

> It is, however, a channel by which malicious guests might theoretically
> exchange data whilst bypassing security checks.  


Yes. It is up to security researchers to bring this "theoretically" into a "real" context before selling solutions to users/customers. Very hard problem.

>This is only reallyan issue
> in Mandatory Access Control systems, and even there there are liable to be
> many other covert channels too.

The question that might arise in the future is where to start restricting covert channels and how to balance the trade-off between security and performance/code intrusiveness of security configurations. To find a trade-off, we need bandwidth estimates for covert channels, which likely depend on the VMM configuration (noise on this covert channel can depend on how many VMs are running, what kind of resource control is applied, etc.).

Are covert channel analysis tools available that apply to the C language and the programming environment of Xen?

The Chinese Wall policy available in the Xen Access Control Module offers a first trade-off between security and utilization (risk mitigation): it supervises which VMs can run at the same time on the same system. In doing so, it controls the VMs among which the hardware resources and hypervisor resources are shared.

> > Is it possible to read memory content of guest domain B (or domain 0) from
> > guest domain A?
>
> No.  On x86 you can only read memory if you can map it with the pagetables
> (i.e. no direct physical addressing).  You can therefore only read the memory
> contents of another domain if you can create a pagetable mapping for that
> domain.  Xen validates any updates to the pagetables to make sure that they
> are safe, so a domain can't create arbitrary mappings to other domains - if
> it tries to make an illegal mapping, Xen won't allow the pagetable updates.

Thanks
Reiner
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel