** Changed in: canonical-devices-system-image
Status: Confirmed => Fix Committed
** Changed in: canonical-devices-system-image
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
No, this was more subtle, its the setting of duid->en.id in
https://github.com/systemd/systemd/commit/dbe81cbd2a9#diff-
893ccaa839a00a7a16a80dbc02631270L54 . This was caught by the two DHCP
test cases. That struct uses ((attribute __packed__)) unions with an
uint32_t preceeding the "id" field, and
On Mon, Nov 16, 2015 at 03:49:15PM -, Martin Pitt wrote:
> > the only place where an unaligned 'out' argument is passed to
> siphash24_finalize() in practice is the test case
> No, also in networkd.
The code I see here in src/libsystemd-network/sd-dhcp-server.c is:
ui
> the only place where an unaligned 'out' argument is passed to
siphash24_finalize() in practice is the test case
No, also in networkd. Anyway, fixed upstream in
https://github.com/systemd/systemd/commit/dbe81cbd2a9 . A more robust
fix for the main issue now landed as well (avoiding the malloc, wh
On Mon, Nov 16, 2015 at 08:03:57AM -, Martin Pitt wrote:
> It's still in siphash, due to a similar problem with the out argument:
> 0x2a02a9e8 in siphash24_finalize (out=0x2a065229 "", state=0xbefff970) at
> src/basic/siphash24.c:182
> 182 *(le64_t*)out = htole64(state->v0 ^ state
I fixed the unaligned out parameter now in the upstream PR. 228 is
around the corner, so the simplest way would be to let this land
upstream and get fixed through a new upstream version, but if this turns
out to cause further blocking crashes I can also cherry-pick it.
--
You received this bug no
It's still in siphash, due to a similar problem with the out argument:
0x2a02a9e8 in siphash24_finalize (out=0x2a065229 "", state=0xbefff970) at
src/basic/siphash24.c:182
182 *(le64_t*)out = htole64(state->v0 ^ state->v1 ^ state->v2 ^
state->v3);
I'll follow up on the upstream PR.
I cleaned this up a bit and forwarded to
https://github.com/systemd/systemd/pull/1911 .
Without this patch, about a third of the unit tests fail with SIGBUS.
With this fix, only ./test-dhcp{,6}-client still SIGBUS, apparently not
due to siphash24. I'll take a look at this as well.
--
You receive
This bug was fixed in the package systemd - 227-2ubuntu2
---
systemd (227-2ubuntu2) xenial; urgency=medium
* debian/patches/siphash24-unaligned.patch: fix siphash24
implementation to handle unaligned inputs. Closes LP: #1512323.
-- Steve Langasek Sat, 14 Nov 2015
23:22:39 +
Thanks Steve for pointing out /proc/cpu/alignment! Yesterday I tried to
reproduce this on an armhf box without success, but with "echo 4 >
/proc/cpu/alignment" this reproduces perfectly well. I'll forward your
patch upstream.
--
You received this bug notification because you are a member of Ubu
** Also affects: android (Ubuntu)
Importance: Undecided
Status: New
** Changed in: android (Ubuntu)
Status: New => Triaged
** Changed in: android (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Bug #1516331 opened against launchpad, to get the buildd behavior
changed to catch issues like this in the future.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512323
Title:
devices on devel-propo
Investigation shows that the test case is triggering kernel fix-ups for
unaligned access, as shown by the incrementing counters in
/proc/cpu/alignment on cady. I'm investigating to see if the phone
kernels have a different default behavior for alignments (SIGBUS vs.
fixup).
So I have a valid test
And here is a disassembly of a locally-built siphash24_compress, built
using the same toolchain as was used for building systemd, which I have
been unable to get to crash with unaligned input.
The code is identical with only differences in the addresses, except for
this rather surprising bit at th
I've assembled a test case for systemd, but I can't get it to fail on
the armhf porter box or under qemu. Architecture documentation suggests
that unaligned 64-bit reads/writes with ldrd/strd are allowed on ARMv7.
But an unaligned access is still exactly what SIGBUS is supposed to
represent, which
** Changed in: systemd (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512323
Title:
devices on devel-proposed/ubuntu do not boot with systemd 227-2ub
Well, no guarantee of alignment > 1 byte. There is a guarantee of 1
byte alignment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512323
Title:
devices on devel-proposed/ubuntu do not boot with sy
In the failing case, the argument to le64toh() is a result returned by
basename(). Yeah, no guarantee of alignment >= 1 byte when taking a
pointer into the middle of a filename.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://
Oh wow, Launchpad just stopped sending me emails on this issue and I got
side tracked on some changes to system-image that I thought might help
debug the problem. At least it looks like y'all have some good leads on
the root cause though.
--
You received this bug notification because you are a m
stack trace points at new hashtable functionality within systemd.
The crash shows udevd is crashing with SIGBUS.
The new siphash24.c code is full of dereferences of uint8_t types that
are then being handled as uint64_t values, as in le64toh() which is
defined as:
static inline uint64_t le64toh(l
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512323
Title:
de
** Description changed:
Last known good build: mako devel-proposed/ubuntu r336
Affects builds from devel-proposed/ubuntu starting from first Xenial
build.
Test Case:
Boot in fastboot mode and flash with:
$ ubuntu-device-flash -v touch --channel=ubuntu-touch/devel-proposed/ubuntu
Crash reports on errors.u.c
systemd-logind:
https://errors.ubuntu.com/oops/d3f3bbc2-8a16-11e5-8423-fa163e525ba7
systemd-udevd:
https://errors.ubuntu.com/oops/d265ba26-8a16-11e5-a6d8-fa163e4aaad4
urfkilld: https://errors.ubuntu.com/oops/f0ef4368-8a16-11e5-9c44-fa163e339c81
--
You received this
Martin, it looks like we have a critical regression in systemd for the
phone in xenial (which of course didn't stop in xenial-proposed now that
we have no automated phone boot tests). Please look at this ASAP.
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
24 matches
Mail list logo