[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Fwd: about page table
Please don't top-post.
At 09:32 +0800 on 13 Sep (1315906354), ???? wrote:
> Sorry for my posting question in such a bad manner.Actually I want to
> rebuild a GuestOS including vcpu and memory , and allow dom0 to modify
> the memory such as page table.In this way, I can experiment some test
> such as monitor attack and rebuild the attack for the sake of
> researching.Back to my problem,I have discover a piece of code in Xen
> to get the mfn from virtual address inside Guest OS.But when I eager
> to change the mfn that the entry points to.Something went wrong.
What? What went wrong?
> static unsigned long
> dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val)
> l3_pgentry_t l3e, *l3t;
> l2_pgentry_t l2e, *l2t;
> l1_pgentry_t l1e, *l1t;
> unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu->arch.cr3);
> unsigned long mfn = cr3 >> PAGE_SHIFT;
> DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id,
> cr3, pgd3val);
> if ( pgd3val == 0 )
> l3t = map_domain_page(mfn);
> l3t += (cr3 & 0xFE0UL) >> 3;
> l3e = l3t[l3_table_offset(vaddr)];
> mfn = l3e_get_pfn(l3e);
> if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
> return INVALID_MFN;
> l2t = map_domain_page(mfn);
> l2e = l2t[l2_table_offset(vaddr)];
> mfn = l2e_get_pfn(l2e);
> if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) ||
> (l2e_get_flags(l2e) & _PAGE_PSE) )
> return INVALID_MFN;
> l1t = map_domain_page(mfn);
> l1e = l1t[l1_table_offset(vaddr)]; //--------------------------(1)
> mfn = l1e_get_pfn(l1e); //--------------------------(1)
> return mfn_valid(mfn) ? mfn : INVALID_MFN;
> For example,what should I do if I want to modify the mfn that l1e
> entry points to?Seems that changing the value of l1e is not enough.
Yes, like I said:
> > OK, I guess from the code below that you want to change the contents of
> > a PV guest's pagetables from inside Xen? That's not really allowed --
> > since PV guests make their own pagetables you need to have the guest
> > OS's cooperation.
so you can't just batter this guy's pagetables without having him
involved - otherwise your guest OS will probably crash in its own
reference counting code when it comes to modify its pagetables later.
In fact, just changing the MFN will break xen's own reference counting as
> I am working through my way to modify do_mmu_update to make it
> available inside the Xen and use it to modify the page table.Am I in
> the right path.Thank you for answering it.
That's a better idea but you still have to worry about the guest.
If you want to change the VA->MA mapping without the guest seeing what
you've done you should turn on shadow pagetables for the guest,
and make whatever changes you like there (in _sh_propagate()).
The problem with that is that Xen's shadow pagetables don't index by VA,
they shadow actual pagetable pages, so
(a) if the guest uses the same pagetable page in the mapping of two
different VA ranges, your modification will apply to both
(Thta's true of the approach you're taking above, as well).
(b) it's not always clear which pagetable page maps which VA so
it might be tricky to know when to make your changes.
Now, if you step back and look at your original problem, I think it
might be better to either
- have the guest make the pagetables that you wanted in the first place
and then just have the PT verification code in 86/mm.c check that it
has done the right thing;
- see if you can do what you want in a HVM guest by making changes to
the guest-physical-to-machine-physical (p2m) mappings.
Xen-devel mailing list