Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

Returning EINVAL would make sense, as that's what a pre-seccomp kernel or a kernel built without seccomp support would do.

I worked around this in APT for now by ignoring EFAULT or rather, printing a warning. It would be nice to not do this though.

FYI - this is from http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00417.html

Upstream response looks good, but not committed there yet.

@Julian - given the case will you need this as an SRU as well or is it only tied to newer apt (or newer apt use cases)?

Test queues in Bionic are still stalling this, there was an error on an iso test on s390x which seemed unrelated to the update - I retriggered for now as I'd assume it needs a newer fixed daily iso.

v2 of the patch (https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01199.html) has been accepted upstream, though it isn't in master yet.

@pmaydell It's actually https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00828.html :)

@paelzer It mostly depends how people run a apt 1.6 foreign architecture chroot with the same pointer size as the host architecture - if they install qemu-user inside the chroot, they're fine, if they copy an old version from the outside, they're not. If the copying is common, we might want to SRU that back to xenial and newer I guess.

This was blocked migrating on a autopkgtest for a known issue now resolved.
TL;DR no bionic images. Resolved now, should migrate soon.

While the final fix now accepted in linux-user is slightly different, the difference is only a comment. It is therefore fine if we pick this up on next merge for Bionic.

Once complete I can plan SRU uploads for this.

I think we can skip SRUing this, apt now has a new workaround based on execve()ing with QEMU_VERSION=meow, which calls qemu-user to exit with 0. It executes a program guaranteed to exit with 1, and just disables seccomp if that exits with 0.

https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=243acdee176dd90cb2838690cb5abbd64d4da905

It's hacky, but it works :)

Ok, thanks for the info Julian!

This bug was fixed in the package qemu - 1:2.10+dfsg-0ubuntu4

---------------
qemu (1:2.10+dfsg-0ubuntu4) bionic; urgency=medium

  * Apply linux-user-return-EINVAL-from-prctl-PR_-_SECCOMP.patch from
    James Cowgill to prevent qemu-user from forwarding prctl seccomp
    calls (LP: #1726394)

 -- Julian Andres Klode <email address hidden> Sat, 04 Nov 2017 00:21:14 +0100

See it passed [1] but britney not picking up.
Giving it some time to do so.

[1]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/open-iscsi/20171114_135029_17bf1@/log.gz

LP, this was unfair to reverse-pass me :-)
Anyway - done - thanks Julian and James C. for your work on that.

Fix has been released with QEMU 2.11:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a8b154a637b586441b