Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

[Julian Andres Klode]

qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here.

I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported.

[Julian Andres Klode (juliank)]

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

[Julian Andres Klode (juliank)]

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.

[Christian Ehrhardt  (paelzer)]

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.

[Peter Maydell (pmaydell)]

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.

[Julian Andres Klode (juliank)]

@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.

[Christian Ehrhardt  (paelzer)]

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.

[Julian Andres Klode (juliank)]

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 :)

[Christian Ehrhardt  (paelzer)]

Ok, thanks for the info Julian!

[Launchpad Janitor (janitor)]

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

[Christian Ehrhardt  (paelzer)]

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

[Christian Ehrhardt  (paelzer)]

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

[Thomas Huth (th-huth)]

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