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=2
@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 the
** Bug watch added: Debian Bug tracker #880582
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880582
** Also affects: qemu (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880582
Importance: Unknown
Status: Unknown
--
You received this bug notification because yo
** Changed in: qemu (Ubuntu)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1726394
Title:
Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)
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.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Importance: Undecided => Medium
** Changed in: qemu (Ubuntu)
Returning EINVAL would make sense, as that's what a pre-seccomp kernel
or a kernel built without seccomp support would do.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1726394
Title:
Passes throug
Public bug reported:
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
retu
