Re: [Xen-devel] [PATCH] Protocol change of suspending through xenbus [and 1 more messages]

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2011-03-31 at 18:46 +0100, Ian Jackson wrote:
> Frank Pan writes ("[Xen-devel] [PATCH] Protocol change of suspending through 
> xenbus"):
> > Xend/libxl uses polling on suspending PV/PV-on-HVM guests.
> > They simply check whether the guest has been suspended again
> > and again. Guest has no chance to report errors to Xend/libxl.
> 
> I don't think this protocol is necessarily correct.
> 
> However I'm not sure the current code in libxl is correct either.  It
> assumes that any value other than "suspend" in control/shutdown is a
> guest ack.

Hmm, it's a bit of a short coming in the protocol -- if someone writes
something to the key which is not the ack we are waiting for we've got
no way of knowing if the guest has acked the request or not and
therefore whether it is just about to make the suspend hypercall or not
and so it's hard to know how we could recover.

It would strictly speaking be a bug in the guest for the guest to write
anything other than "" when acknowledging a request, but in practice any
write will do.

IMHO it is a bug in the toolstack to allow a second request to be made
while one is currently outstanding. I'm not sure if xl has such a bug or
not...

> > The following patch is for libxl. It creates a key in the xenbus:
> > control/shutdown-error. Guest can post any error string into this
> > key, and also libxl can return this error to the user/administrator
> > asap.
> 
> What character set is this string in ?  What if it contains hostile
> data ?  etc.

Not to excuse it but I think we already have this problem since the PV
driver frontends will write error strings to an error node
(xenbus_dev_error in the pvops kernel).

I think it's generally understood to be simple ASCII text, although I
doubt it is even as well defined as that.

One subtle difference with this case is that the device error messages
(AFAIK) are not propagated so there is no issue with ensuring the
toolstack side is robust (since it doesn't exist). Also there is also no
danger of an admin seeing them out of context (e.g. interleaved with
toolstack generated logging) and not realising they are from the guest,
if we are worried about that sort of attack.

> I think it might be better to report the details of the error in the
> guest kernel logfile.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel