Bug#880582: apt: apt update hangs under qemu-user when host and target architecture are 64-bit
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
Reply to: