Re: [Xen-devel] Sharing Memory between userspace of dom0 and userspace of domU

["Derek Murray" <Derek.Murray@xxxxxxxxxxxx>]

Hi Mike,

On Feb 19, 2008 4:16 PM, Mike Sun <msun@xxxxxxxxxx> wrote:
> > > At the moment, yes, the only way to grant access to a page is from the
> > > kernel. This is due to the fact that kernel memory corresponds to
> > > physical memory, and we don't have to worry about interactions with
> > > the swapper, or what happens when the process dies.
>
> From what I understand of what you've said, are you saying that the
> shared memory pages that granted access must always be in physical
> memory and cannot be swapped out, even if the guest kernel decided to
> for some reason?  Does Xen enforce this in any way, e.g. pinning the
> pages somehow?

A shared (granted) page is shared based on its (G)MFN. There is in
fact no interaction with Xen when granting a page, as this can be done
by simply writing to the grant table.

The granted physical page is pinned when it is mapped, however, this
only means that, if the granting domain dies, the page is not freed
erroneously.

However, as far as I can tell, the granting domain is free to do
whatever it likes with the physical page. Therefore, if the process
containing the granted page dies, you need to keep a reference to the
physical page that was granted, because another domain has mapped it
and can therefore read the contents of the page, or overwrite them.
This could cause a security problem or unexpected behaviour in the
granting domain.

Likewise, if the kernel decided to swap out the page that you granted,
and replace it with another virtual page, you would not  observe the
effect of granting access to a particular virtual address (which is
all you would know about in user-space). Therefore you would have to
pin the page using mlock() or something similar.

I hope this makes things clearer, but let me know if anything I've
said doesn't make sense.

Regards,

Derek Murray.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel