So with full virtualization using HVM's Xen is responsible for
maintaining shadow page tables for each HVM. So does that mean Xen has
to trap every write _and read_ to the HVM page table and do address
translation from P2M(write) and M2P(read)? I assume if that's true the
global tables go away, a HVM wouldn't know they existed anyway. Are
there any other strategies for safe page table access that don't involve
Xen (writable page tables with HVM)? It seems like the full
virtualization strategy could be quite expensive, although it seems
pretty safe.
Thanks for the clarification.
-Travis
P.S. Is it safe to send pictures to the list? I don't know if that's
kosher or not so I'm holding off.
--- Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote:
> > When the virtualized hardware (VT-x or Pacifica)
> is available, I assume
> > that there is no more need for sharing a single
> table for memory management
> > because guest OSs will not know there is such
> table exists. Is there any
> > documentation that explains how to manage memory
> when virtualized hardware
> > is used?
>
> There's no documentation to explain it but you might
> find some mailing list
> posts if you search around the archives a little.
>
> Full virtualisation implies using shadow page
> tables. The guest isn't allowed
> to manage the pagetables the hardware uses anymore.
> Instead, the hypervisor
> is responsible for monitoring the pagetables the
> guest tries to install,
> translating the addresses in them and installing a
> real pagetable that will
> produce the behaviour expected by the guest. This
> task is complicated by a
> number of things: it's necessary to trap guest
> attempts to write directly to
> its own pagetables, and it's necessary to propagate
> accessed and dirty bits
> back to the guest pagetables from the host
> pagetables.
>
> HTH,
> Mark
>
> > Thanks,
> >
> > Myong
> >
> > -----Original Message-----
> > From: Mark Williamson
> [mailto:mark.williamson@xxxxxxxxxxxx]
> > Sent: Thursday, February 16, 2006 11:22 AM
> > To: mkang@xxxxxxxxxxxxxxxx
> > Cc: xense-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xense-devel] Xen memory management
> >
> > > 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
>
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
Home