[libvirt] [PATCH v2] lib: Add note that bulk stats API queries may overrun RPC buffers

[Richard W.M. Jones]

On Wed, May 24, 2017 at 04:16:45PM +0200, Michal Privoznik wrote:
> On 05/24/2017 02:47 PM, Richard W.M. Jones wrote:
> > 
> > On Wed, May 24, 2017 at 12:49:58PM +0200, Michal Privoznik wrote:
> >> That's quite exact. I mean the word 'guessing'. We can't really provide
> >> reliable way of dealing with what you're suggesting (unless we cut the
> >> limit really small) nor we can guarantee atomicity. Therefore I think it
> >> would be a waste of time to work on this. Yes, it can be done, but the
> >> benefits are pretty small IMO.
> > 
> > Why is atomicity a problem?
> 
> The atomicity steps in depending on what level we are talking about
> serialization. If we do it the way Martin suggested (= on public API
> level) then the list of domains may change between two iterations of the
> suggested loop. Thus the result obtained would not reflect the reality.
> However, if we are talking on RPC level, then there's no atomicity
> problem as RPC is 'blind' to the data (it doesn't care what data is sent).
> 
> > Just structure the libvirtd
> > messages so that you have:
> > 
> >   COLLECT_THE_STATS
> >     - saves the stats into an internal buffer in libvirtd
> >       and returns a handle and a number of stat items
> >   RETURN_THE_STATS
> >     - returns partial subset of previously collected stats,
> >       called multiple times to transfer the data back to libvirt
> >   FREE_THE_STATS
> >     - free the internal buffer
> 
> This is exactly what I was proposing in my e-mail that I linked in the
> other thread. You just wrote it more cute. Yet again, what's the
> gain/advantage of this over one big message?

In the libguestfs case there is an actual security concern.  The
daemon runs in the untrusted context of the guest, where a malicious
guest filesystem or program could (in some cases quite easily) send
back arbitrarily large messages to the library, tieing up infinite
resources on the host.

In libvirt the danger is possibly more on the other side (modified
library sends infinitely large message to libvirtd).  There's also an
issue of libvirt connecting to a compromised remote host.

Whether having a maximum message size prevents all such attacks I'm
less clear about, but it probably helps against simple ones.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v