Re: [Xense-devel] Xen memory management

[Reiner Sailer <sailer@xxxxxxxxxx>]

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