Re: [Xense-devel] Xen memory management

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> 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