[systemd-devel] Compatibility between D-Bus and kdbus

[Simon McVittie]

On 01/10/14 17:58, Daniel Mack wrote:
> On 10/01/2014 03:33 PM, Simon McVittie wrote:
>> The message header (fixed-length header and header fields) is limited to
>> 2 MiB in kdbus, whereas on dbus-daemon it may be up to a configurable
>> limit, by default 32 MiB for the system bus or 128 MiB for the session
>> bus. Broadcast messages (header + body) have the same 2 MiB limit, but
>> unicast message bodies may be any size: kdbus itself does not impose any
>> limit.
> 
> The intention is that larger payloads should be sent using memfds, which
> kdbus doesn't have to copy around at all. sd-bus does the magic and
> offload larger payloads automatically.

Right, and that's why I said unicast messages have no practical size
limit (the D-Bus Specification says < 128 MiB - I haven't checked
whether sd-bus actually enforces that to ensure round-trips between
kdbus and stream-based D-Bus are possible, or whether the proxy just
drops giant messages). However, broadcasts aren't allowed to carry memfd
payloads for the same reasons they aren't allowed to carry attached fds,
as far as I could see, so the 2 MiB limit still applies there.

Admittedly, 2 MiB per broadcast is fairly generous, but on this first
pass through kdbus I was trying to raise every possible incompatibility,
even if it isn't a problem in practice (like the 585 year timeout thing).

> That's true, it's different, and we want to avoid such a big lock here.
> However, we do have a per-domain sequence number that is filled into the
> message once it hits the kernel via KDBUS_CMD_MSG_SEND. As it is per
> domain, it even guarantees message ordering across different buses such
> as the system and the session bus.

OK, so that fixes the eavesdropping case, assuming you're saving the
messages to analyze later.

It would probably be good if there was an official way to serialize
kdbus messages, with their full kdbus_msg headers, into a blob of bytes,
suitable for recording in files. Will Thompson proposed pcap as a common
container format for D-Bus messages when read/written by
monitoring/debugging tools like his Bustle utility, and it seems as good
as any other. Perhaps we could reserve D-Bus message format version 3
for an encapsulated kdbus_msg, containing a nested version-2 message in
its payload? Or define separate pcap packet types for "D-Bus message"
(already exists) and "encapsulated kdbus_msg" (doesn't yet)?

>> * Some operations that are method calls in stream-based D-Bus are
>>   synchronous ioctls in kdbus. This can result in apparently
>>   paradoxical situations
>
> Right. The ioctl will return on the fd before the notification can be
> dequeued from the message pool. That's a design change. But as you say
> yourself, that's hardly a problem if userspace waits for notifications
> to arrive in its message pool rather than operating on the return value
> of the ioctl. So I don't think that's much of a problem.

So are you suggesting that a synchronous API like
dbus_bus_request_name() may return when the ioctl does, but an
asynchronous API like g_bus_own_name() should defer its asynchronous
return until the NameOwnerChanged-equivalent? That seems a reasonable
approach, although worth writing about.

    S