All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: ???? <19890121wr@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Fwd: about page table
Date: Tue, 13 Sep 2011 09:00:45 +0100	[thread overview]
Message-ID: <20110913080045.GE79171@ocelot.phlegethon.org> (raw)
In-Reply-To: <CAF2sySP=kdPukHJeBi8iUSFzzrjTf2dCZHwwtMiVt3=E5Camfg@mail.gmail.com>

Hello, 

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[0]->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);
>         unmap_domain_page(l3t);
>         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);
>     unmap_domain_page(l2t);
>     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)
>     unmap_domain_page(l1t);
> 
>     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
well.

> Now
> 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;
or
 - see if you can do what you want in a HVM guest by making changes to
   the guest-physical-to-machine-physical (p2m) mappings.

Cheers,

Tim.

      reply	other threads:[~2011-09-13  8:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 14:31 about page table 吴锐
2011-09-12  9:16 ` Fwd: " 吴锐
2011-09-12 10:10   ` Tim Deegan
2011-09-13  1:32     ` 吴锐
2011-09-13  8:00       ` Tim Deegan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110913080045.GE79171@ocelot.phlegethon.org \
    --to=tim@xen.org \
    --cc=19890121wr@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.