[virt-tools-list] [PATCH 22/22] spice: hook into QMP port

[Marc-André Lureau]

Hi

On Tue, Aug 7, 2018 at 12:01 PM, Daniel P. Berrangé <berrange at redhat.com> wrote:
> On Tue, Jul 31, 2018 at 03:41:25PM +0200, marcandre.lureau at redhat.com wrote:
>> From: Marc-André Lureau <marcandre.lureau at redhat.com>
>>
>> If the "org.qemu.monitor.qmp.0" port is available:
>> - enable the VM UI
>> - get and follow the VM state
>> - send the requested VM actions
>>
>> This adds a json-glib dependency on spice-gtk display. If necessary,
>> we could make it optional.
>
> This patch is something I much don't much like the precedent / idea
> of. Its only stop/pause/resume right now, but over time this will
> inevitably expand and end up re-implementing much of libvirt's QMP
> monitor handling, but worse. For example, the patch below has a CVE
> in it because it is not limiting the amount of data it reads before
> the \r\n pair, so a malicious QEMU can make it consume GB worth of RAM.

True, low impact, easy to fix.

> I would suggest it should use libvirt for these actions, but that
> kind of defeats the goal of what you're trying to achieve by providing
> a UI that is usable by standalone QEMU.
>
> The other thing that occurs to me is that the idea of remote power
> control is interesting / useful for pretty much all uses of SPICE and
> VNC with QEMU, even when libvirt is managing QEMU.
>
> As it stands we would not want to expose the monitor over SPICE in
> many cases as it gives the SPICE user way too high privileges, but
> remote power control is useful especially for cloud users. A way
> to force a reboot of a dead/hung guest from the SPICE client instad
> of having to jump out to openstack CLI API for example.
>
> In VNC there was a 3rd party extension defined to allow remote power
> control actions over VNC.
>
> Thus I think SPICE could define a remote power control extension of
> its own that could be safely enabled in all cases, even where the
> remote user is unprivileged. This is portable to all SPICE server
> side impls that care to provide it since it would not be QMP.

If we have to define a new channel, new protocol messages etc, this
will overlap with what QMP is already providing.

Qemu or Spice could filter/limit the QMP monitor to a subset of commands/events.


>
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|