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: mkang@xxxxxxxxxxxxxxxx
Subject: Re: [Xense-devel] Xen memory management
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 16 Feb 2006 16:21:43 +0000
Cc: xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Feb 2006 16:37:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <003c01c63312$d3a93ef0$1c02000a@Myong1>
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: <003c01c63312$d3a93ef0$1c02000a@Myong1>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> I am just wondering what does it take (including design modification) to
> limit the global access to the whole table.

The reason there's a single shared table is that M2P mapping needs to be fast 
for guests.  A table lookup is obviously fast (index by machine address, get 
a physical address) but requires a lot of space.  Maintaining a single table 
enables the guests to do this fast lookup without requiring a large amount of 
machine memory to be devoted to per-guest M2P tables.

The most straightforward solution would be to maintain a separate table for 
each guest.  This could probably be done without breaking the existing guest 
ABI.  It would be rather more memory intensive, however.

In principle, a guest could maintain its own M2P table instead of there being 
a shared one - Xen wouldn't need to supply it at all.  This would still incur 
a per-guest memory cost, and some extra complexity in the guest.

> I think every little action 
> that limits unnecessary sharing of resources among guest domains will help
> achieve multi-level secure Xen that is included in Xen research roadmap.

Agreed.  It's worth thinking about where things might leak and considering 
options for plugging / limiting those holes.

Cheers,
Mark

> Thanks,
>
> Myong
>
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@xxxxxxxxxxxx]
> Sent: Thursday, February 16, 2006 9:28 AM
> To: xense-devel@xxxxxxxxxxxxxxxxxxx; mkang@xxxxxxxxxxxxxxxx
> Subject: Re: [Xense-devel] Xen memory management
>
> > 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."
> >
> > The questions are:
> > What does it mean by "globally readable"? Which hypercall is being used
> > to access this table from a guest domain (or is there some other way to
>
> access
>
> > this table from a guest domain)?
>
> 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.
>
> It is, however, a channel by which malicious guests might theoretically
> exchange data whilst bypassing security checks.  This is only really an
> issue
> in Mandatory Access Control systems, and even there there are liable to be
> many other covert channels too.
>
> > 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.
>
> Cheers,
> Mark

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