| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home