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

[Fedor Lyakhov]

Hi Simon,

Thanks for your reply!

On Wed, Jan 22, 2014 at 3:02 PM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> 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 :-)

I do not know the numbers - that can be measured once we have some
prototypes working. The real-world numbers will depend on the exported
services and their applications, obviously. But we expect it to be
manageable low in our media services use case. Only media controlling
messages are to be transported, not the media streams. So there
shouldn't be high requirements on the bandwidth. As for latency - it
should be of the order of network latency between the client and the
host... At least currently media applications work at the guest
entirely, dealing with similar latencies on user actions - this is
inevitable for VDI.

For GStreamer example the payload would be something like "create a
pipeline", "get/set properties", "start/stop playing", "seek" etc.
There is a GstBus message bus though, so there are various messages
coming from pipline to application. In our use case we're going to
filter only high-level messages like EoS (end of steam), error, state
changed and few more - to allow high-level GStreamer-based
applications like media players to work. Complex applications
extensively using many piplines and low-level bus messages may pose
issues here - this needs investigation...

There are two other media back-ends we want to expose similarly to
GStreamer: Google WebRTC internal media engine and VLC. We have some
knowledge of WebRTC engine APIs - they seem to be O(1) for each
telephony app action like making a call etc. There are call backs as
well - they'd need to be filtered and/or throttled similarly...
Exporting WebRTC engine would be useful for media redirection of web
browsers using that API (theoretically - in practice this can be very
tough to make it work...); and also many proprietary softphones use it
internally as it was prominent GIPS framework formerly...

We do not have any background on VLC unfortunately - this is something
to explore.

Another one important framework to support is Telepathy. We don't have
background there, but from the very high-level view we know the
Telepathy is modular with modules connected via D-Bus - seems like
there is a perfect opportunity to replace local media engine module
with remote one at the guest... on the other hand, Telepathy is based
on Farstream, which afaik is based on GStreamer eventually - so using
remote GStreamer may be an option (not the best one, as it is probably
the case of complex application...).

>
>> 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.)
>

I see.

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

Right. I expect that in our use case there shouldn't be large messages
normally - and dealing with many small messages should be done via
filtering (and throttling where applicable). Also I understand that
not every application can be supported - probably existing
applications would need to be fixed - but we want to minimize these
efforts.

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

Thanks for clarification!

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

I think that our main use case of media services should be in the
session bus in a normal, non-VDI use case. I'm just trying to think in
a more general way - so that our approach can be extended to other use
cases if possible.

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

Spice client is something similar to VNC or RDP client - just very
different internally. Spice client connects to Spice server exposed by
QEMU-KVM process of user's virtual machine running at the host. User
is capable of doing anything within his virtual machine - in essense,
he can see the screen of the VM all the time, even including the BIOS
boot display (more than you'd expect from VNC). So user certainly can
gain guest root and so on via Spice client. Also there are 2 daemons
running at the guest - they are called Spice Agent (one is run as
root, another one is per-session) - they provide additional UX
enhancements like shared clipboard, file transfer, automatic display
resolution change etc.

On the other hand, normally guest shouldn't originate execution of
code at the client side... Something we're changing.

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

Ok, looks like this is our case. Further question: should we implement
independent stubs for each such service, or is it possible to
pass-through client's services transparently? Maintaining individual
stubs can be tedious...

> 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".

Sounds good... but with recent kdbus introduction it won't have a
chance to be accepted upstream - so would be ungrateful... Also we're
starting with Linux client - Linux guest now, but later there may be
need for other systems in various combinations, namely Android as
client and Windows as guest. We are very ambitious :)

>
>     S
>
> [1] or, when ready, the kdbus-to-traditional-D-Bus bridge
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus



-- 
Best regards,
Fedor