Re: [RFC 1/4] libxl: Learned to send FD through QMP to QEMU

[Anthony PERARD <anthony.perard@citrix.com>]

On Tue, Mar 27, 2018 at 11:58:45AM +0100, George Dunlap wrote:
> On 03/27/2018 11:29 AM, Ian Jackson wrote:
> > This 2nd patch looks reasonable, but it prompted to notice two new
> > kinds of hazard introduced by the deprivileging design goal:
> > 
> >>  int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename, bool live)
> >>  {
> > ...
> >> +    rc = qmp_synchronous_send(qmp, "add-fd", NULL,
> >> +                              qmp_fdset_add_fd_callback, &new_fdset,
> >> +                              qmp->timeout);
> >> +    if (rc)
> >> +        goto out;
> > 
> > By this point, a depriv'd qemu must be assumed to be compromised by
> > its guest - ie we must treat it as hostile.
> > 
> > This is not consistent with use of qmp_synchronous_send, because
> > qmp_synchronous_send will block with both the domain and ctx locks
> > held.  That is, a malicious qemu can deny service; it even has the
> > ability to prevent its serviced domain from being destroyed.
> 
> Will qmp_synchronous_send() wait forever, or is there a timeout?

There is some kind of timeout, but I'm not sure it is true at all time.

This is a few functions that does handle connection/send/receive:
- qmp_open()
  this one as a 5s timeout on connecting to the socket.
- qmp_send()
  This use write/sendmsg with no timeout, but the fd is set to
  O_NONBLOCK.
- qmp_next()
  This function use select with a 5s timeout, so read should not block.
  But I think the timout is reset every time something have been read
  from the socket.

So I guess a malicious qemu could have the qmp_next() function wait
forever.

Also I think every time a "response" or an "event" is processed,
qmp_next() will return, and qmp_synchronous_send() will call qmp_next
again until it got the response it is waiting for.

So a few opportunity to wait forever.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel