D-Bus in virtual desktop infrastructure connecting client services and guest apps

[Simon McVittie]

On 21/01/14 23:24, Fedor Lyakhov wrote:
> * Guest's application (e.g. media player) linked with GStreamer stubs,
> converting function calls into actual D-Bus calls to gstd at the
> client.

What sort of data rate (messages/sec and bytes/sec) do you expect this
to have, and what sort of latency? I suspect that D-Bus over Spice over
TLS over TCP might not have the world's greatest performance
characteristics :-)

> 1. Does using D-Bus make sense in our circumstances?

"Maybe". I see D-Bus as conceptually a signalling protocol, not a bulk
data protocol: it's appropriate for things that only happen when
something "interesting" happens, but less appropriate for things that
happen all the time. I don't know which of those is more like your use-case.

(For instance, in Telepathy, we send D-Bus messages for instant
messages, VoIP call events like ringing/answer/hang-up, and the
beginning and end of file transfers - but we bypass D-Bus for the actual
VoIP data, and for the actual file-transfer data.)

One of the goals of kdbus (see recent threads) seems to be to make D-Bus
cope better with bulk data while keeping its ease-of-use
characteristics, mainly by doing clever tricks with fds and zero- or
one-copy transfer through the kernel; but in your case, you can't get
away from serializing everything into a networked bytestream, so you'll
still need to think about D-Bus in the way it's traditionally been used,
as a signalling protocol.

> a) Use peer-to-peer connections and private D-Bus service at the
> client, do not use any bus at all. That's how Telepathy D-Tubes are
> implemented, for instance.

If you look at it from the right angle, this is also how dbus-daemon is
implemented. It's just a complicated libdbus application, really :-)

> b) Provide client services (gstd) with access to guest's bus.

There are two well-known D-Bus buses.

The system bus contains system services, and user applications that need
to talk to them. If you are connected to the system bus as uid 1000, you
have all the privileges of uid 1000.

The session bus is conceptually one per login session (e.g. X11 session)
and contains user applications. Only one uid may connect. In general,
there is no privilege separation: if you are connected to uid 1000's
session bus, you have all the privileges of uid 1000 (we consider it to
be OK for session services to offer API that includes arbitrary code
execution).

Current systemd designs replace the session bus with a user bus that is
conceptually one per uid, shared between one or more concurrent login
sessions, but other than that it's very similar. In particular, it has
the same security properties.

Which bus are you trying to forward, or is the answer "both" or "some
new, parallel bus"?

What's your security model between the Spice client and the guest? Is
each allowed to execute arbitrary code on the other, or are there
limitations in one direction?

If the client is allowed to execute arbitrary code on the guest, I would
be inclined to go for a model where the majority of services run on the
guest, but selected services are replaced by a stub which forwards
messages to the real service on the client. Doing this the naive way
(forwarding D-Bus streams individually and keeping the star topology,
with the centre of the star on the guest, and most client-to-client
communication also passing through the guest) would be OK if the "real
services" on the client don't listen to too many broadcast signals.

If they listen to a lot of the same broadcast signals, then you might
need to do something cleverer, which I think would have to involve
modifying dbus-daemon[1] to have the concept of "multiplex everything
that's for client A, B and/or C into this socket".

    S

[1] or, when ready, the kdbus-to-traditional-D-Bus bridge