add new classifier result

1 files changed, 77 insertions, 0 deletions

diff --git a/results/classifier/105/other/1726394 b/results/classifier/105/other/1726394
new file mode 100644
index 00000000..889918f5
--- /dev/null
+++ b/results/classifier/105/other/1726394
@@ -0,0 +1,77 @@
+other: 0.918
+instruction: 0.908
+device: 0.898
+assembly: 0.887
+semantic: 0.859
+graphic: 0.855
+KVM: 0.848
+socket: 0.845
+vnc: 0.813
+network: 0.812
+boot: 0.799
+mistranslation: 0.720
+
+Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)
+
+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.
+
+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
+