Two Disco containers (one per PPA)
$ sudo add-apt-repository ppa:paelzer/bug-1830859-with-proposed-seccomp
or
$ sudo add-apt-repository ppa:paelzer/bug-1830859-without-proposed-seccomp
# add main/debug and enable the deb-src in the PPA sources
$ sudo apt install gdb qemu-system-x86 qemu-system-x86-dbgsym dpkg-dev
$ apt source qemu
$ cd qemu-3.1+dfsg/
break on qemu_seccomp
Hrm ??
equal qemu source
Good:
Breakpoint 1 at 0x4d63f4: file ./qemu-seccomp.c, line 293.
Bad:
Breakpoint 1 at 0x4d63f4: qemu_seccomp. (2 location
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004d63f4 in qemu_seccomp at
./qemu-seccomp.c:293
1.2 y 0x00000000004d656e in qemu_seccomp at
./qemu-seccomp.c:244
Now the second hit isn't an actual qemu_seccomp call, but it is very
close to the error that we get reported.
(gdb) l qemu-seccomp.c:293
288
289 #if defined(SECCOMP_FILTER_FLAG_TSYNC)
290 int check;
291
292 /* check host TSYNC capability, it returns errno == ENOSYS if
unavailable */
293 check = qemu_seccomp(SECCOMP_SET_MODE_FILTER,
294 SECCOMP_FILTER_FLAG_TSYNC, NULL);
295 if (check < 0 && errno == EFAULT) {
296 add = true;
297 }
(gdb) l qemu-seccomp.c:244
239 error_setg(errp, "invalid argument for
resourcecontrol");
240 return -1;
241 }
242 }
243
244 if (seccomp_start(seccomp_opts) < 0) {
245 error_setg(errp, "failed to install seccomp syscall filter "
246 "in the kernel");
247 return -1;
248 }
Well maybe with seccomp 2.4 development headers something changed and this now
gets inlined?
That is not an error, but suspicious.
qemu_seccomp should ALWAYS be inlined
static inline __attribute__((unused)) int
qemu_seccomp(unsigned int operation, unsigned int flags, void *args)
The one at line 293 is at seccomp_register and depends on #if
defined(SECCOMP_FILTER_FLAG_TSYNC).
This one is active in both cases.
But the one at line 244 is part of qemu_seccomp_get_kill_action
That has some checks as well being:
#if defined(SECCOMP_GET_ACTION_AVAIL) && \
defined(SCMP_ACT_KILL_PROCESS) && \
defined(SECCOMP_RET_KILL_PROCESS)
There is no other way to "avoid" the path of
parse_sandbox -> seccomp_start -> qemu_seccomp_get_kill_action ->
qemu_seccomp
in terms of precompiler.
Both have CONFIG_SECCOMP set, so it might really come down to the three checks
above.
Reading the commit [1] that added this to qemu seems to match the
current theories.
Lets see what happens when it tries to use things buildt with 2.4 but
without 2.4 being installed at runtime.
The returned value for action is matching expected /usr/include/seccomp.h
numbers:
- good case => 196608 ==> SCMP_ACT_TRAP = 0x00030000U
- bad case => 2147483648 ==> SCMP_ACT_KILL_PROCESS = 0x80000000U
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
For qemu I could patch out the usage of SCMP_ACT_KILL_PROCESS, but:
- that is stupid as it is preferred if available
- the question is either
- how can we make such rebuilds pick up the dependency correctly
- could we runtime (instead of compile time) detect if SCMP_ACT_KILL_PROCESS
is available
[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=bda08a5764d
** Description changed:
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
