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

[Witold Baryluk]

Depends on architecture. On i386 and amd64 there is zero impact for exams.

32 bit arm would be impacted, but considering dbus is not heavily used by
anything in the first place, and there is 1000 other instructions around,
the impact would be extremely small if any. Most likely it will be actually
faster.

I do see real world misaligned reads on alpha, and I did trace it to
mentioned function . Thus the bug.

If there is some other code in dbus that ensures pointers are aligned, then
something is not quite working, because CPU complains on alpha to me.

On Thu, 18 Jul 2019, 19:17 Simon McVittie, <smcv at debian.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20190719/e941ca13/attachment.html>