On Thu, 2007-09-13 at 14:36 +0800, Peter Teoh wrote:
> Thank you for the answer, but I am still totally confused....apologies
> here.
>
> On 9/13/07, pradeep singh rautela <rautelap@xxxxxxxxx> wrote:
> On 9/13/07, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
> [...]
> > Thank you for the answer. In the first place, we will not
> know what is
> > pagetable or non-pagetable memory. For example, during
> dom0/domU
> > initialisation, the guest OS will query the e820 bios
> mechanism for physical
> > memory availability, and the guest OS (paravirt or HVM)
> will then assign
> > different parts of the physical memory for pagetable
> construction. Then
> > after all the pagetable is completely constructed, the CR3
> is loaded, which
> > started the hardware MMU operation. So therefore, before
> the CR3 is
> > loaded the entire physical memory is marked as readonly, and
> after the CR3
> > is loaded, only those memory not involved in pagetable
> mapping are unmarked
> > readonly?
> >
> > Does not seem right, as guest OS can change the CR3 anytime
> subsequently as
> > well.
>
> Any writes to CR3 'll be trapped to the Xen itself AFAIK. So,
> yes any
> guest can change the CR3 anytime but there is always Xen to
> see what
> it is writing in the CR3 .Anything beyond the memory assigned
> to
> domain is illegal, xen knows the limits of the domains.
>
> This part I fully understand. But the guest OS, knowing that he owns
> the entire memory range, will attempt to partition the entire blocks
> of memory in any design he wants to - whether it be pagetable memories
> or not. And so the contents in memory can be anything, there is no
> concept of "invalid frame number" to the guest OS, and will remain as
> what the guest OS has written - no change, ie hypervisor cannot change
> its content.
>
> But the hypervisor will implement a shadow memory (apologies if I am
> wrong, just describing based on the all the materials I have read so
> far) - this construction (done in hypervisor) is triggered immediately
> upon loading of CR3 by the guest. And the purpose of the shadow
> memory is to rewrite all the pagetable entries in the guest to its
> real/physical values, so that it can be used for pagetable mapping by
> MMU. This rewriting process is done in hypervisor, based on the
> memory assigned to the guest, and so it has to be ALWAYS valid values.
> It is needed because hypervisor cannot change the content of the guest
> pagetable. The guest should always be able to write ANYTHING he
> wants to, to his own guest memory. And the hypervisor will always
> generate the VALID mapping values to put into the shadow memory.
>
> So throughout the entire chain of reasoning, there is no way for the
> guest to corrupt the shadow table in the hypervisor. The only reason
> I can think of, that pagetable in guest must be made readonly, is so
> that it will trigger the corresponding pagetable update in the shadow
> memory in the hypervisor. Nothing to do with valid/invalid frames
> numbers here, or "unsafe" values either. Does it sound logical?
>
> Please correct me if I am wrong.
You need to make it clear whether you are talking about paravirutalised
(PV) or fully-virtualised (HVM) mode guests, they are very different in
this regard.
What you say is roughly true for HVM guests but not PV guests where
there is no shadow mode.
In the HVM case the shadowing code ensures that guest page-table pages
are marked read-only in the shadowed page tables (the ones actually
loaded into cr3) in order to trap and propagate updates.
For PV guests the guest is required to perform the psuedo-physical to
machine address translation itself. The hypervisor enforces the
invariant that the guest cannot have a writable mapping to a page table
page using the algorithm described in the Xen paper[0], section 3.3.3.
On startup the initial pagetables are marked readonly and the guest has
to make other pages read-only if it wishes to use them as page tables.
[0] http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home