[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xense-devel] Xen memory management

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.

Xense-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.