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
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.
It started with some of my usual KVM checks and found them failing on Disco with: 28T17:10: 17.121934Z qemu-system-x86_64: -sandbox on,obsolete= deny,elevatepri vileges= deny,spawn= deny,resourceco ntrol=deny: failed to install seccomp syscall filter in the kernel
error: internal error: process exited while connecting to monitor: 2019-05-
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: deny,elevatepri vileges= deny,spawn= deny,resourceco ntrol=deny
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox on,obsolete=
With strace I found different behavior: SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000011> SECCOMP_ SET_MODE_ STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000044> SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, {len=68, filter= 0x55f2b7a5e2d0} ) = 0 <0.000251>
Good:
[pid 3487] 0.000000 seccomp(
[pid 3487] 0.003136 seccomp(
[pid 3487] 0.000250 seccomp(
Bad: SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000017> SECCOMP_ GET_ACTION_ AVAIL, 0, [SECCOMP_ RET_KILL_ PROCESS] ) = 0 <0.000014> SECCOMP_ SET_MODE_ STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000013>
[pid 484] 0.000000 seccomp(
[pid 484] 0.002680 seccomp(
[pid 484] 0.000088 seccomp(
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. SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000015> SECCOMP_ GET_ACTION_ AVAIL, 0, [SECCOMP_ RET_KILL_ PROCESS] ) = 0 <0.000013> SECCOMP_ SET_MODE_ STRICT, 1, NULL) = -1 EINVAL (Invalid argument) <0.000013> SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000022> SECCOMP_ GET_ACTION_ AVAIL, 0, [SECCOMP_ RET_KILL_ PROCESS] ) = 0 <0.000017> SECCOMP_ SET_MODE_ FILTER, SECCOMP_ FILTER_ FLAG_TSYNC, {len=68, filter= 0x564de3852560} ) = 0 <0.000288>
Strace now looks like:
[pid 1788] 0.000000 seccomp(
[pid 1788] 0.004167 seccomp(
[pid 1788] 0.000098 seccomp(
[pid 1788] 0.000054 seccomp(
[pid 1788] 0.000061 seccomp(
[pid 1788] 0.001477 seccomp(
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. 19.10.3 already migrated.
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.
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.
### some related Build logs ### /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
Cosmic rebuild against 2.4, not affected by the issue
https:/
Disco rebuild against 2.4, affected by the issue /launchpadlibra rian.net/ 425689546/ buildlog_ ubuntu- disco-amd64. qemu_1% 3A3.1+dfsg- 2ubuntu3. 2~ppa1_ BUILDING. txt.gz
https:/
Disco build against 2.3 (working) /launchpadlibra rian.net/ 422884897/ buildlog_ ubuntu- disco-amd64. qemu_1% 3A3.1+dfsg- 2ubuntu3. 1_BUILDING. txt.gz
https:/