Control: severity 757037 grave Control: tags 757037 + patch I'm bumping this bug up to grave severity, because it seems it makes this liblzo2 version entirely useless on a fairly common armel CPU (my armel has a Marvell Kirkwood armv5tel, as used in the SheevaPlug and its derivatives) in the default Debian configuration. It also makes liblzo2 FTBFS on such machines, because the tests fail.
On Sun, 09 Nov 2014 at 21:26:37 +0100, Marc Kleine-Budde wrote: > So from my point of view switching unaligned access > off in libzop with -DLZO_CFG_NO_UNALIGNED should be done on at least > ARMel. Are there other alignment sensitive platforms in debian? (Please Cc me, I am not subscribed to this bug. Non-maintainer contributors to Debian bugs usually aren't.) I think alignment-sensitivity is the common case, and quietly accepting unaligned accesses (and giving the correct answer!) as is done on x86 is the exceptional case... According to http://www.ibm.com/developerworks/library/pa-dalign/ the mips family are alignment-sensitive, and so is powerpc sometimes, although it might do automatic fixup. According to https://bugs.launchpad.net/ubuntu/+source/zmqpp/+bug/1256886 Ubuntu armhf is alignment-sensitive (presumably Debian armhf is the same?) I've also seen references to sparc not liking unaligned accesses. s390 can do unaligned accesses fine according to http://lxr.free-electrons.com/source/include/asm-s390/unaligned.h?v=2.2.26, but realistically, who's going to test that? Not me :-) I think the safest thing would be to use -DLZO_CFG_NO_UNALIGNED on all Debian architectures except i386, amd64, and maybe the powerpc family if someone can test those. I attach a patch that restricts use of unaligned accesses to i386 and amd64 CPUs (any kernel); it's easy to extend to whitelist other CPUs where unaligned accesses are OK. liblzo2 does actually try to avoid using unsafe unaligned accesses by using a structure typedef struct lzo_memops_TU2_struct { unsigned char a[2]; } lzo_memops_TU2; and only doing a type-punning assignment similar to[1] *(lzo_memops_TU2 *) (void *) dest = *(const lzo_memops_TU2 *) (void *) src; if that structure has required alignment 1... but it seems (recent?) gcc might be optimizing that into a single 2-byte operation which requires alignment. This might be a gcc bug, but then, I suspect this might be a violation of strict aliasing (hence undefined behaviour) if you get all language-lawyer about it. Pessimistically assuming that we have to access byte-by-byte on miscellaneous architectures seems both quicker and safer than working out whether this is the compiler's fault. tl;dr: the attached patch works, I would suggest using it. Regards, S [1] Actually it's a little more complicated than that; there are another couple of layers of typedef between the source code and the reality
diffstat for lzo2-2.08 lzo2-2.08 changelog | 9 +++++++++ rules | 6 ++++++ 2 files changed, 15 insertions(+) diff -Nru lzo2-2.08/debian/changelog lzo2-2.08/debian/changelog --- lzo2-2.08/debian/changelog 2014-07-15 02:03:18.000000000 +0100 +++ lzo2-2.08/debian/changelog 2014-11-11 23:48:48.000000000 +0000 @@ -1,3 +1,12 @@ +lzo2 (2.08-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Define LZO_CFG_NO_UNALIGNED on non-x86. Without this flag, lzo2 sometimes + performs unaligned word accesses which cause initialization + checks to fail, in particular on armel (Closes: #757037). + + -- Simon McVittie <[email protected]> Mon, 03 Nov 2014 10:24:18 +0000 + lzo2 (2.08-1) unstable; urgency=low * New upstream release (closes: #752861) (CVE-2014-4607) diff -Nru lzo2-2.08/debian/rules lzo2-2.08/debian/rules --- lzo2-2.08/debian/rules 2013-08-26 20:24:58.000000000 +0100 +++ lzo2-2.08/debian/rules 2014-11-11 23:48:48.000000000 +0000 @@ -10,6 +10,12 @@ DEB_MAKE_CHECK_TARGET = check test DEB_DH_MAKESHLIBS_ARGS = --add-udeb=liblzo2-2-udeb +# We know i386 and amd64 are OK for unaligned accesses but the safe +# assumption is that unknown architectures aren't. +ifeq ($(filter i386 amd64,$(DEB_HOST_ARCH_CPU)),) +CPPFLAGS += -DLZO_CFG_NO_UNALIGNED +endif + common-install-impl:: mkdir -p $(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH) mv $(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so.* $(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH)
