[Pkg-utopia-maintainers] Bug#932381: libdbus-1-3: lidbus _dbus_marshal_write_basic uses implementation defined behaviour (unaligned read)

[Simon McVittie]

Control: severity -1 normal
Control: tags -1 + upstream

On Thu, 18 Jul 2019 at 17:15:09 +0200, Witold Baryluk wrote:
> In this case, value is often not aligned to native uint64 alignement,
> and dereference does lead to a CPU trap on some architectures
> and some compilers.

Do you have evidence of libdbus accessing misaligned pointers in real use,
or is this concern based on compiler warnings or reading the source code?

libdbus goes to considerable lengths to ensure that marshalling always
acts on correctly aligned pointers, despite appearances to the contrary:
the message wire-format is designed to ensure that all values are
naturally-aligned, and commit 6327adafe20603fce3c7507e20f300e07398b517
(first released in dbus 1.4.x in 2011) asserts at compile time that this
is sufficient to give them their correct alignment.

However, it is not immediately obvious to a reader or to the compiler
that this is the case, and in particular you'll get compiler warnings
when building dbus on strongly-aligned architectures like ARM.

> I suggest to change all dereferences to types bigger than 1 byte to
> use memcpy

I have been meaning to try this for a while (git says my work-in-progress
branch is from 2015), but this is hampered by not having a realistic
benchmark that can assess whether it improves or reduces performance.

> On 32-bit arm, it will pesimize correctly to read and combined aligned
> reads (which is in total 3 extra instructions). On architectures like
> 32-bit ARM, and Alpha (64-bit), MIPS (both 32 and 64 bit), 32-bit PowerPC
> the resulting code with memcpy will in fact be faster than current code,
> because it will not trap and emulate read in kernel, which is very slow.

If the current code is, in fact, always accessing correctly-aligned
pointers (so the trap-and-emulate case is something that could in theory
happen, and would be slow if it happened, but is never actually reached),
how much of a performance hit is expected for using memcpy and having the
pessimized code generated?

    smcv