Endianness issues with systemd <-> dbus communication

[Lennart Poettering]

On Thu, 13.03.14 13:12, Fridrich Strba (fridrich.strba at suse.com) wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello, good people,
> 
> On 12/03/14 14:14, Simon McVittie wrote:
> > From the code you quoted, it seems sd_bus correctly distinguishes 
> > between those two two header fields (at least in that snippet -
> > there might be a bug elsewhere).
> 
> There is some news on this front. It seems that the culprit are the
> hashmap functions, which are used to store and retrieve the
> reply_callback structures of asynchronous calls. They take a uint64_t
> pointer for the key argument. Nevertheless, the reply_cookie of the
> sd_bus_message is stored in a 32bit variable.

Internally sd-bus keeps these ids as 64bit values, since kdbus has them
as 64bit. sd-bus will never generate these as 64bit values though, and
dbus in its payload only uses 32bit values.

> This works by a sheer luck on x86-64:
> - - it's little endian, and
> - - the struct is padded to the next 8 byte boundary because
> reply_cookie is between two pointers.
> 
> s390x being a 64-bit big endian, this fails, resulting in complete
> failure of any communication between systemd and the dbus-daemon. It
> never gets past the initial Hello handshake, sent as an asynchronous
> message.
> 
> We are currently looking into a proper solution, since simply changing
> that variable to uint64_t fixes some stuff, but breaks things elsewhere.

Can you check if 42c4ebcbd4cbd7b27667eb8081ee4dc46f9ece17 which I just
commited to systemd git fixes this for you?

Thanks for tracking this down!

Lennart

-- 
Lennart Poettering, Red Hat