On Thu, Nov 02, 2017 at 02:49:07PM +0000, James Cowgill wrote: > Package: apt > Version: 1.6~alpha3 > Severity: important > > Hi, > > I noticed that with apt 1.6, running apt-get update hangs in a mips64el > chroot running on an amd64 host using qemu-user-static. I can also > reproduce this with an arm64 target so I suspect this affects all 64-bit > architectures running on amd64. > > It outputs this before hanging (on mips64el): > > # apt-get update > > 0% [Working]qemu: Unsupported syscall: 5312 > > 0% [Working] > > Syscall 5312 is "seccomp". > > If I run qemu-user with the -strace option, I see that the http method > calls the seccomp syscall which fails with ENOSYS (since it's not > supported in qemu). Then, libseccomp calls the old prctl(PR_SET_SECCOMP) > syscall which succeeds. I think in this case a valid seccomp filter is > installed, but for the wrong architecture. This results in the calling > thread being immediately killed when a syscall is later executed. > > The apt changelog mentions checking for EFAULT in case apt is started > inside QEMU. I think this only works by chance on 32-bit targets because > they would pass a truncated pointer to the real prctl which the kernel > would usually reject as an invalid address.
Sure, and there's nothing I can do about it. QEMU needs to be fixed in https://bugs.launchpad.net/qemu/+bug/1726394 Nobody is reacting there. Unless you know how to reliably detect qemu-user, then that's easy - we could even just install filters for the host architecture. > > I think the hanging is caused by the http method having two threads. > When an invalid syscall is executed under seccomp, only the calling > thread is killed. Since the http method is running two threads, the > other is left running and hangs. In turn this causes the parent apt > process to wait for the http method to exit which will never happen. Are there two threads? I only know one. Anyway, this is supposed to call a signal handler which calls _exit, but apparently the signal handler was not called, or rather, presumably write(2) and _exit(2) were blocked by the invalid seccomp filter. -- Debian Developer - deb.li/jak | jak-linux.org - free software dev Ubuntu Core Developer de, en speaker