Re: [Qemu-devel] [PATCH 0/3] Add dbus-vmstate

[Daniel P . Berrangé]

On Wed, Jul 10, 2019 at 10:53:10AM +0200, Paolo Bonzini wrote:
> On 08/07/19 18:04, Daniel P. Berrangé wrote:
> > The downside of using the bus daemon is that we have to spawn a new
> > instance of dbus-daemon for every QEMU VM that's running on the host,
> > which is yet more memory overhead for each VM & another process to
> > manage, and yet another thing to go wrong.
> > 
> > QEMU already has a direct UNIX socket connection to the helper
> > processes in question. I'd much rather we just had another direct
> > UNIX socket  connection to that helper, using D-Bus peer-to-peer.
> > The benefit of debugging doesn't feel compelling enough to justify
> > running an extra daemon for each VM.
> 
> Would it be possible to make QEMU the broker?  That is, how hard would it
> be to embed a minimal DBus broker (which only takes care of connecting servers
> and clients---stuff like launching servers would be completely out of scope)?

What would be the benefit of embedding it in QEMU ? I see significant
security downside to that which would mean its not something I'd want
to support.

If we accept the need for a bus then this implies there's a need for
service <-> service messages, where neither service is QEMU. This in
turn requires enforcement of security policies for the separation of
services. It is highly desirable, if not mandatory, to have such
security enforcement outside the QEMU address space, given that QEMU
is an untrustworthy component.


> Would it for example make sense to split the bus handling part of dbus-broker
> into a library that QEMU could reuse?  (And if we plan to do this, should QEMU
> use sd-bus instead of gdbus?)
> 
> In QOM that would be something like
> 
>   -object dbus-connection,id=client1,chardev=...,addr=foo       # p2p
>   -object dbus-vmstate,connection=client1                       # the 
> interface
> 
>   -object dbus-connection,id=client1,addr=foo                   # via 
> external daemon
>   -object dbus-vmstate,client=client1                           # the 
> interface
> 
>   -object dbus-session,id=session1,chardev=...
>   -object dbus-connection,id=client1,session=session1,addr=foo  # via 
> internal daemon
>   -object dbus-vmstate,client=client1                           # the 
> interface

>From my POV I only see two viable options. Either p2p with no bus & QEMU
being one endpoint so there's no requirement for security policies, or
bus based mesh with an external process to enforce security policy.

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 :|