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: xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xense-devel] Xen memory management
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 16 Feb 2006 16:31:17 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Feb 2006 16:46:29 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OF5FC5CB9A.5B5178E1-ON85257117.0053992E-85257117.0058F918@xxxxxxxxxx>
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>
References: <OF5FC5CB9A.5B5178E1-ON85257117.0053992E-85257117.0058F918@xxxxxxxxxx>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> > 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.

Yep.  It doesn't leak any security-related information just by being there, 
but it could certainly be used as a signalling channel.

> 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

It's updated using a hypercall - the hypercall could of course be rate-limited 
but this might impact performance.  I'm not sure that doing this would affect 
performance much in most cases, but it'd have an impact on network IO.

> 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?)

Full details in my other e-mail...  Essentially there's no benefit to being 
able to see another domains mappings, but maintaining a per-domain M2P would 
imply a substantial extra space usage.

Less-flexible memory allocation could be used to limit the necessary size of 
the M2P (i.e. allocate in larger chunks, instead of a per-page basis), I 
guess, but this would require changes to the IO model to work well (consider 
page flipping).

> 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.

*nod*

> 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?

I guess a straightforward way might just be to write code to exploit these 
covert channels?  It'd certainly be quite interesting and would give a 
concrete measure of bandwidth (nb. an analysis of covert channels and their 
bandwidth in one or more modern enterprise-class VMMs would make an 
interesting paper!)

There's probably a surprisingly large set of possible covert channels - 
particularly once you consider dom0.

Cheers,
Mark

> 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

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

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