domU reading its own xenstore home directory from userspace

domU reading its own xenstore home directory from userspace

[Andrew D. Ball]

What does this statement in the xenbus documentation on the xen wiki
mean: "The DomU kernel interface is structured in such a way that nodes
in the "home directory" of the domain cannot be addressed, and therefore
cannot be read from or written to. Tools may use this space to store
data that should not be accessed by the domain itself." ?
[ from http://wiki.xensource.com/xenwiki/XenBus , toward the bottom ]

I thought domU kernels must read data in the domU's home directory or is
the data that drivers watch somewhere else?

I want to read this data from domU userspace that that a domU can find
out what it's UUID is.  This is important for correlating domU's with
the dom0's they run on for management tools.  Reading a UUID from a
domU's xenstore home directory from domU userspace is the cleanest way
to do this that I can think of at the moment.

Thanks for your help.

Andrew

Re: domU reading its own xenstore home directory from userspace

[Anthony Liguori]

This documentation is old and at the time referred to the Xenbus code, 
not the userspace interface (there wasn't even such an interface at the 
time).

Are you having problems using libxenstore from within a domU on recent 
builds?

Regards,

Anthony Liguori

Andrew D. Ball wrote:

>What does this statement in the xenbus documentation on the xen wiki
>mean: "The DomU kernel interface is structured in such a way that nodes
>in the "home directory" of the domain cannot be addressed, and therefore
>cannot be read from or written to. Tools may use this space to store
>data that should not be accessed by the domain itself." ?
>[ from http://wiki.xensource.com/xenwiki/XenBus , toward the bottom ]
>
>I thought domU kernels must read data in the domU's home directory or is
>the data that drivers watch somewhere else?
>
>I want to read this data from domU userspace that that a domU can find
>out what it's UUID is.  This is important for correlating domU's with
>the dom0's they run on for management tools.  Reading a UUID from a
>domU's xenstore home directory from domU userspace is the cleanest way
>to do this that I can think of at the moment.
>
>Thanks for your help.
>
>Andrew
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: domU reading its own xenstore home directory from userspace

[Ewan Mellor]

On Fri, Dec 02, 2005 at 03:45:11PM -0500, Andrew D. Ball wrote:

> What does this statement in the xenbus documentation on the xen wiki
> mean: "The DomU kernel interface is structured in such a way that nodes
> in the "home directory" of the domain cannot be addressed, and therefore
> cannot be read from or written to. Tools may use this space to store
> data that should not be accessed by the domain itself." ?
> [ from http://wiki.xensource.com/xenwiki/XenBus , toward the bottom ]
> 
> I thought domU kernels must read data in the domU's home directory or is
> the data that drivers watch somewhere else?
> 
> I want to read this data from domU userspace that that a domU can find
> out what it's UUID is.  This is important for correlating domU's with
> the dom0's they run on for management tools.  Reading a UUID from a
> domU's xenstore home directory from domU userspace is the cleanest way
> to do this that I can think of at the moment.

The permissions checking in Xenstore have recently been re-enabled, so I shall
explain.  The text on the wiki is wrong in any case.

Any guest can read any part of the store, but _only_ if it has permission to
do so.  Domain 0 may read or write anywhere in the store, regardless of
permissions, and permissions are set up by the tools in domain 0, or by
Xenstored when it first starts up.

The store structure looks like this:

/tool/xenstored      xenstored-specific storage
/tool/...            available for other tools

/vm/<uuid>/name        VM name
          /uuid        VM UUID
          ...          other VM-specific details

/local/domain/<domid>/vm       Path to this domain's VM store entries
                     /...      other domain-specific details

In domain 0's section, you would expect to see

/local/domain/0/backend/<deviceClass>/<frontendID>/<deviceID>/...

Whereas for an unprivileged guest you would expect

/local/domain/<domID>/device/<deviceClass>/<deviceID>/...

These two directories are for the backend and frontend drivers for each
device, respectively.

It is up to Xend (or other tools) to set up the permissions on the appropriate
sections on the store.  It sets /vm to be readable only by domain 0,
/local/domain/<domid> to be read-write by the guest, and
/local/domain/0/backend/XYZ to be read-write by dom 0, read-only by the guest,
for each of the guest's devices.

Note that this means that to do what you want (read the UUID from the /vm
path) will require a change to Xend to make that node readable by the guest.


The permission semantics for Xenstore are a bit strange, so I shall explain
those too.

There is are calls in the Python layer -- xstransact.SetPermissions and
xstransact.set_permissions -- and a corresponding C layer call --
xs_set_permissions -- each of which takes a path, and a list of (domid,
permissions) pairs.  I shall use the Python syntax, as this is clearer.  In
this case, read and write flags are specified, which are packed into the
"permissions" field in the tuple.

xstransact.SetPermissions(path, { 'dom'   : dom1,
                                  'read'  : True,
                                  'write' : False },
                                { 'dom'   : dom2,
                                  'read'  : True,
                                  'write' : True },
                                { 'dom'   : dom3,
                                  'read'  : True,
                                  'write' : True })

This looks clear, but actually the semantics of this are strange.  The first
element in this list specifies the owner of the path, plus the read and write
access flags _for_every_domain_unspecified_subsequently_.  The owner _always_
has read and write access to their nodes.  The subsequent entries are normal
capabilities.  The example above, therefore, sets the permissions on the path
to be such that domain 0 (being privileged), dom1 (being the owner), and
domains dom2 and dom3 (being explicitly specified) can _all_ write to the
node.  Any other domain can only read, as specified by the first pair of
'read' and 'write' flags.

Finally, please note that permissions in the store are inherited from parent
to child, but _only_ when the child is created.  This means that if you do

write('/tool/mytool/foo', 'Hi')
write('/tool/mytool/bar', 'Hello')
set_perms('/tool/mytool', { 'dom'   : 0,
                            'read'  : True,
                            'write' : True })

then foo and bar will not necessarily be read/write everybody!  They will
instead have the permissions of /tool/mytool at the time of the writes, so if
/tool/mytool did not exist at the time, then foo and bar will be unreadable by
anyone except dom0 and the domain that created them.

Xend is careful to do

rm('/local/domain/<domid>')
mkdir('/local/domain/<domid>')
set_perms('/local/domain/<domid>', { 'dom' : <domid> })

for this very reason.

HTH,

Ewan.

Re: domU reading its own xenstore home directory from userspace

[Charles Duffy]

Ewan Mellor wrote:
> /local/domain/<domid>/vm       Path to this domain's VM store entries
>                      /...      other domain-specific details
>   
One question: Can a domain retrieve its own domid?

Let's say I have /tool/foo/<domid>/key, and I set permissions such that
each domU has appropriate access to its own /tool/foo/<domid>/key. Does
a tool running within the DomU need to iterate through all the
/tool/foo/*/key options until it finds one it has access to, or is there
a better way to determine one's own domid?