Checked on the PPA: root@d-wily:~# apt install libseccomp2=2.3.3-3ubuntu2 Reading package lists... Done Building dependency tree Reading state information... Done [...] The following packages will be REMOVED: qemu-kvm qemu-system-x86 The following packages will be DOWNGRADED: libseccomp2 0 upgraded, 0 newly installed, 1 downgraded, 2 to remove and 0 not upgraded.
... and similar. So the dependency works and makes sure a recent libseccomp2 will have to go along and by that prevent the error. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1830859 Title: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4 Status in libseccomp package in Ubuntu: Won't Fix Status in qemu package in Ubuntu: Triaged Bug description: [Impact] * Just as of yesterday we have a new libseccomp in all releases. This brings some new code and features which might impact packages. For qemu being one of the few that is not so much a problem in many cases. Prior to Disco we didn't have code in qemu using the new libseccomp bits. In Eoan we can assume that libseccomp 2.4 (being release level) will be installed. But in Disco people might have installed and not updated libseccomp but install/upgrade to a qemu that was built against that new libseccomp. Due to that qemu will get a runtime dependency that is not picked up automatically - this would break all qemu execution being blocked by a failure to install seccomp filters. * To fix that we will add an explicit versioned dependency to qemu to make sure the rebuild will ensure that the right library version is available. * This is needed for qemu-system* which all depend on qemu-system- common so to avoid too much noise changing all qemu-system* packages the dependency it added there. [Test Case] * ensure that the qemu install will ensure that libseccomp2 (>= 2.4.1) is also installed (not staying on 2.3) * Then install qemu and run $ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny which should not trigger this (when fixed) error: internal error: process exited while connecting to monitor: 2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed to install seccomp syscall filter in the kernel [Regression Potential] * Well, the regressions might be triggered by pushing the new libseccomp, not by this dependency fixup. The security Team has checked and this seems to be the only affected code in the archive. So libseccomp was pushed to fix CVEs. I have thought if it is a regression that users of qemu will now be forced to use the newer libseccomp, but since it would be unusable without that is no important argument. And it is strongly recommended to upgrade for security reasons as well. [Other Info] * n/a --- It started with some of my usual KVM checks and found them failing on Disco with: error: internal error: process exited while connecting to monitor: 2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed to install seccomp syscall filter in the kernel I realized it works on X/B/C/E but not in a D container It worked ~4 weeks ago. This test can be simplified to one command: $ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny With strace I found different behavior: Good: [pid 3487] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000011> [pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000044> [pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251> Bad: [pid 484] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000017> [pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_KILL_PROCESS]) = 0 <0.000014> [pid 484] 0.000088 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000013> The difference seems to come from being built against seccomp as in Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad). The dependency on the built package stayed libseccomp2 (>= 2.3.0) It did not pick up 2.4 via e.g. shlibs. If I install libseccomp2 2.4 from -proposed the issue is gone. Strace now looks like: [pid 1788] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000015> [pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_KILL_PROCESS]) = 0 <0.000013> [pid 1788] 0.000098 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000013> [pid 1788] 0.000054 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000022> [pid 1788] 0.000061 seccomp(SECCOMP_GET_ACTION_AVAIL, 0, [SECCOMP_RET_KILL_PROCESS]) = 0 <0.000017> [pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288> This is in all releases proposed to fix CVE-2019-9893 I was just ?lucky? to pick it up with my qemu build in the PPA that has proposed enabled. Now there might be some toolchain detail to this as well. As I built qemu for B/C as well and they built against the proposed 2.4 versions as well. But in B/C things work with new qemu builds and old libseccomp2 installed. Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3 already migrated. But that "luck" of B/C working might be specific to Qemus code, other rebuilds against the new libseccomp2 might fail as well in B/C and further. Shlibs detection is based on these symbols but my new qemu build is not calling these so it dependency stays at 2.3. Until a simpler testcase is found, I have set up two new PPAs: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp In comment #5 I debugged the case and found the new "dependency" As a summary: - the libseccomp-dev 2.4 headers being installed at build time - code can detect now the availability of SCMP_ACT_KILL_PROCESS - code might decide to use SCMP_ACT_KILL_PROCESS - if code runs without libseccomp2 2.4 installed it breaks ### some related Build logs ### Cosmic rebuild against 2.4, not affected by the issue https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz Disco rebuild against 2.4, affected by the issue https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz Disco build against 2.3 (working) https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
