WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] XenStore permissions from kernel space

On Jun 15, 2006, at 11:27 AM, NAHieu wrote:

Hi James,

On 6/15/06, James Pendergrass <james.pendergrass@xxxxxxxxxx> wrote:
Hello,
I've been working on a kernel module that shares some pages between
to domUs.
In the course of doing this I had the need to communicate information
via XenStore (e.g., the grant references),
but for a number of reasons did not want to use the full XenBus
registration/probe/hotplug...system (it is too dynamic,
and requires a kick off event from dom0 rather than allowing self
organizing shares between domUs).

I established that the only thing preventing my setup of domA writing
to a node in XenStore and domB reading it
was the lack of the xs_get/set_permissions function in the kernel
level xenbus/xenstore interface.  So I ported those
functions down from the userland xenstore libraries.


You mean you want any domU to read any other domU's information
(stored in XenStore)? I doubt that is not a good idea because of
potential security problems.

Any ideas?

Thanks,
H

I think you have overstated my intent. I want a domU kernel to be able to allow
a specific other domU to read a specific node in XenStore.
As it stands now, the userland xenstore libs have xs_set_permissions and xs_get_permissions that allow modification of the permissions of a node in XenStore. These funcs rely on xs_single/xs_talkv to send the appropriate messages to the central xenstore daemon. The xs_single and xs_talkv symbols are (intentionally) not exported to outside the kernel level xenbus driver (which prevents other modules from directly communicating with xenstore). Instead, the xenbus provides typical printf, scanf, watch, and gather methods. But not get/set perms.

The patch I submitted just implements these functions inside the xenbus driver and exports the symbols so that my module (which shouldn't really be of interest to anyone outside of my project) can use these calls to set permissions on a node in xenstore. It happens that my driver opens up one node (read only) for each domain with id 0 to N-1 (i.e. dom3 can read /<my_path>/3 to get the grant reference it needs to
communicate more fully with the domain in question).

Alternatively, the symbols for xs_talkv or xs_single could be exported, but I assume the original developers intentionally did not export these for fear of a rogue driver mucking about with things it
shouldn't.

-aaron

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

<Prev in Thread] Current Thread [Next in Thread>