[13:09] <mdeslaur> cpaelzer: oh, we knew about that one :( [13:09] <cpaelzer> well [13:09] <cpaelzer> then had you a plan how we should resolve that [13:10] <cpaelzer> either in general (magic great code I haven't thought of) or in particular (how I should resolve it for qemu) ? [13:10] <cpaelzer> and good morning mdeslaur sorry to start with such issues :-/ [13:10] <mdeslaur> cpaelzer: good morning! :) [13:11] <-- lborda-eod (lbo...@173-246-24-26.qc.cable.ebox.net) has left this server (Quit: Ex-Chat). [13:11] <mdeslaur> cpaelzer: the plan is to publish the libseccomp update ;) [13:11] --> lborda (lbo...@173-246-24-26.qc.cable.ebox.net) has joined this channel. [13:11] <mdeslaur> cpaelzer: we searched the archive, and qemu was the only problematic package that used those new apis [13:12] <mdeslaur> jdstrand: are we ready to publish the seccomp updates? [13:12] <cpaelzer> mdeslaur: ok then should I add an explicit dependency for Disco [13:12] <cpaelzer> only there the "transition" might occur [13:13] <cpaelzer> that we rebuild with the new version around but the old might be installed [13:13] <jjohansen> hey mdeslaur [13:13] <cpaelzer> I'm prepping an SRU anyway and that would avoid the "rebuilt to 2.4 but not installed" [13:13] <cpaelzer> if qemu really is the only one I'm ok to carry this [13:13] <mdeslaur> cpaelzer: yeah, you can add an explicit dependency, or you can wait until we publish seccomp...we may publish it today or monday [13:13] <cpaelzer> and in Eoan things are fine as that will release with >=2.4 [13:14] <cpaelzer> mdeslaur: well, my point is even if you publish it there are no guarantees [13:14] <cpaelzer> people might update qemu but not libseccomp [13:14] <cpaelzer> and they would be screwed [13:14] <cpaelzer> so the first rebuild of qemu in disco (=now) will need to add the dependency [13:14] <cpaelzer> mdeslaur: ^^ [13:15] <mdeslaur> yes, selective installing of security updates is an untested and probably broken configuration [13:15] <mdeslaur> if you add the explicit dependency, you'll need to wait until we do publish seccomp too [13:15] <cpaelzer> yes, but I'll need a few days anyway [13:15] <cpaelzer> and you seem close [13:16] <mdeslaur> ok [13:16] <cpaelzer> and for testing interim wise I can throw a no change rebuild of libseccomp 2.4 in my ppa [13:16] <mdeslaur> I'll try and remember to add the explicit dependency to the next round of qemu updates [13:16] <cpaelzer> Hmm, you have some in the pipe as well? [13:16] <mdeslaur> I don't currently, no [13:16] <cpaelzer> I have [13:16] <cpaelzer> I'll add them right away [13:17] <cpaelzer> if testing goes well those should hit -unapproved early next week [13:17] <mdeslaur> sorry our timezones don't overlap and you had to spend time debugging this [13:17] <mdeslaur> we spotted this issue when we prepared the emergency qemu update last week
TL;DR we will make is a qemu fix in Disco, by adding an explicit dependency. All others don't need the change. ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Changed in: libseccomp (Ubuntu) Status: New => Won't Fix ** Changed in: qemu (Ubuntu) Status: New => Triaged ** Changed in: qemu (Ubuntu) Assignee: (unassigned) => Christian Ehrhardt (paelzer) ** Changed in: libseccomp (Ubuntu) Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned) ** Changed in: qemu (Ubuntu) Importance: Undecided => Medium -- 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: 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