Andrew D. Ball
2005-Dec-02 20:45 UTC
[Xen-devel] domU reading its own xenstore home directory from userspace
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
Anthony Liguori
2005-Dec-02 23:07 UTC
Re: [Xen-devel] domU reading its own xenstore home directory from userspace
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor
2005-Dec-05 13:06 UTC
Re: [Xen-devel] domU reading its own xenstore home directory from userspace
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Charles Duffy
2006-Jan-16 16:34 UTC
[Xen-devel] Re: domU reading its own xenstore home directory from userspace
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel