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

[James Pendergrass <james.pendergrass@xxxxxxxxxx>]

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