Re: [Xen-devel] XenProject/XenServer QEMU working group minutes, 30th August 2016

[Juergen Gross <jgross@xxxxxxxx>]

On 09/09/16 18:18, Jennifer Herbert wrote:
> QEMU XenServer/XenProject Working group meeting 30th August 2016
> ================================================================
...
> XenStore
> --------
> 
> The xs-restrict mechanism was summarised, and its limitation – it does
> not work though the kernel XenStore driver, which is needed to talk to
> a XenStore domain.  A way to fix this would be to create a wrapper.
> 
> Another approach is to try and remove XenStore from all
> non-priverlaged parts of QEMU – as it is thought there isn't that much
> use remaining.  Protocols such as QMP would be used instead.  PV
> drivers such as QDISK could be run in a separate qemu process – for
> which a patch exists. There where concerns this would like a lot of
> time to achieve.
> 
> Although time ran out, it was vaguely concluded that multiple
> approaches could be run in parallel, where initially xs-restrict is
> used as is, and then a the xenstore wrapper could be developed
> alongside efforts to reduce XenStore use in QEMU.  Even with the
> XenStore wrapper, QEMU may benefit from reducing the number of
> communication protocols in use – ie removing XenStore use.

What about the following:

Split up the transaction ID of Xenstore messages (32 bits) to two 16
bit parts. The high part is a restriction ID (0 == unrestricted).
As the transaction ID is local to a connection 16 bits should always
be enough for transaction IDs: we would still have more transaction
IDs available than domain IDs.

xs-restrict returns a restriction ID to be used for the connection
from now on. This can be easily added by a kernel wrapper without
having to modify the Xenstore protocol: there are just some bits
with a special meaning now which have always been under control of the
Xenstore daemon/domain.

A socket connection with Xenstore daemon using xs-restrict will force
the complete connection to be restricted (as today in oxenstored), while
a connection from another domain (Xenstore domain case) will rely on the
kernel wrapper of the connecting domain to do the restriction ID
handling correctly.

Adding support for that feature in Xenstore daemon/domain is very easy
as the needed modifications should be rather local.


Juergen

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