Hi,
At 21:59 -0500 on 10 Dec (1228946361), Sina Bahram wrote:
> Why do shadow page tables exist in xen for pv guests? What is their purpose,
> and how do pv guests interact with them?
They're used in live migration, to track which of the guest's pages have
been written to. It's described in the paper I mentioned before:
http://www.cl.cam.ac.uk/research/srg/netos/papers/2005-nsdi-migration.pdf
> How does one activate this?
Using the XEN_DOMCTL_shadow_op domctl (see xen/include/public/domctl.h
for details and the uses of xc_shadow_control() in libxc for examples).
> Does one have to have pae enabled for 32-bit pv guests?
Yes.
> I thought I read
> that I do, but when I look at the source, the classic 10, 10, 12 format for
> page tables is supported. Is that not supported for shadow page tables, and
> if so ... How can I learn more about this?
The shadow pagetable code does support non-PAE paging, because it has to
handle HVM guests, which can't be constrained to particular paging
behaviour.
> * general goal *
>
> Here is what I'm trying to do, in a finite way.
>
> I'd like to add a structure, for now a reference in the paging struct would
> be fine, let's call it hash_table2 for lack of a better name.
>
> I'd like to mirror all operations to the page table, to hash_table, in my
> hash_table2.
I'm not sure what hash table you're talking about here. The hash table
in the shadow code just contains the list of which shadows there are of
a guest pagetable, not any page permissions or such.
> Now to the purpose of why I'm doing this.
>
> I'd like to make it so that if a page is accessed, with the supervisory bit
> set, I direct all reads and writes to the original hash_table, but I want to
> direct all executes to hash_table2, or vice versa, that hardly matters which
> one gets which.
>
> Eventually I'd like to not even mirror pages that are just data (read and
> write only) or just code (execute only).
>
> Again, I only want to do this for page swith supervisory bit set so as to
> only affect the kernel's pages. That's the kernel of the pv guest.
>
> In this way, I hope to implement split memory as a way of preventing certain
> attacks to the guest.
Are you thinking of building two sets of shadow pagetables, one with
only execute permissions and one with only write permissions? The CPU
only ever uses one set of pagetables at a time, so you'd never be able
to use the non-executable one.
I think it makes more sense to have just one set of shadow pagetables
but switch the individual mappings of a page back and forth.
In fact, getting into the shadow pagetables is probably just making life
difficult for yourself; if you can use a recent AMD processor that
supports NPT, you could just change p2m map back and forth, and use the
nested-pagefault handler to know when to make the change. Much simpler,
and easier to get right.
By the way, it's not possible using x86 pagetables to have a page that's
executable but not readable.
> Is there anyone I can speak to about this, perhaps over detailed emails, IM,
> or even phone?
This mailing list (xen-devel) is the best place to discuss
implementation details.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home