Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross <jgross@xxxxxxxx>]

On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>>> configurable"):
>>>> So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>> That's rather unfortunate. So in order to be able to make xenstore
>> domain a common setup we need to find a solution for support of
>> xs_restrict() via xenbus, right?
>>
>> TBH, the way xs_restrict() was introduced is rather weird. It is
>> completely bound to the socket interface of oxenstored. So anyone
>> wanting to use xs_restrict() is limited to oxenstored running in
>> dom0. No way to use xenstored or a xenstore domain. I'm really
>> disappointed such a design was accepted and is now the reason for
>> not being able to disaggregate dom0.
>>
>> I've searched through the xen-devel archives and found a very
>> interesting mail:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>>
>> The "restrict" feature was added without any further discussion how
>> it is implemented and that the C-variant doesn't support it. The
>> explicit question about non-existing features in the C xenstored was
>> answered just with "the xenstore wire protocol doesn't change".
>>
>> With:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>>
>> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
>> was added. Again no mentioning of the special implementation in
>> oxenstored.
>>
>> Really, this is not how open source development should be done!
>> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
>> support as it has been introduced in a foul way.
> 
> I don't think the lack of xs_restrict() working over the ring should
> preclude these improvements to the configuration of how xenstored starts up.
> 
> Ideally, this issue would be listed in an appropriate place in
> docs/features/, in the hope that it gets considered and addressed in the
> future.

Digging a little bit deeper I think the current xs_restrict()
implementation renders an oxenstore domain completely useless: as
soon as dom0 tries to use xs_restrict() it will loose its privileges
as the complete dom0 connection will be affected. :-(


Juergen

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