[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xenstore domains and XS_RESTRICT



Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> > There is no socket connection to xenstore domain.
> 
> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
> with domid_id of zero? Or are you saying this is irrelevant becasue
> what you are interested is for the Linux kernel to filter certain
> xsd_sockmsg so it won't do something silly?

The latter.

> OK, so this all sounds like the OS needs to mediate access? Sorry for
> being so dense this morning.

The OS already needs to mediate access for all xenstore commands.  The
kernel xenbus driver has a list of the commands.  Some of them it will
"simply" proxy, translating request id and transaction fields, as
applicable.  Some of them it does something special for.  Unknown
commands are rejected.

> This would imply that the kernel driver would need to understand
> the format and disallow the XS_RESTRICT under certain conditions?

There should be a way to tell the kernel driver that the connection
should be restricted.  XS_RESTRICT is as good as any.

But the XS_RESTRICT command must not be forwarded by the kernel proxy
to the real xenstore.  Rather, the driver must make an annotation in
its client struct instead.

That annotation should result in _every_ proxied xenstore command,
from that client, being decorated so as to specify the restriction
domain.

There needs to be an extension to the xenstore protocol to support
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.