I uploaded 2.1.1-1ubuntu1~trusty3 to fix this issue to trusty-proposed. ** Description changed:
[Impact] A latent bug in libseccomp 2.1.0 and the proposed 2.1.1-1ubuntu1~trusty1 was exposed in the snapd build testsuite when run on amd64. It has to do with libseccomp's state machine not always working correctly when using argument filtering and there were no tests for this particular failure in 2.1. Once 19e6c4aeca9818c4b288b09911dfa4be9a831236 (the upstream test for this issue) is applied to 2.1, you see the failures. Simple seccomp filters that just use the syscall name are not affected by the bug and we only use seccomp arg filtering in one interface which is why Tyler's testing of 2.1.1-1ubuntu1~trusty1 didn't show it either. The snap-confine tests do exercise it, but seccomp argument filtering wasn't added until series 16 and seccomp 2.2.3 had all the fixes already. Porting series 16 snapd/snap-confine and all of snap-confine's arg filtering tests to trusty revealed the bug in seccomp 2.1. [Test Case] A test case is included in the build in debian/patches/bpf-accumulator-check.patch (19e6c4aeca9818c4b288b09911dfa4be9a831236). You can check the amd64 build log to verify no failures. You can also run the snapd testsuite: 0. apt-get install dpkg-dev build-essential linux-libc-dev libseccomp-dev seccomp 1. enable deb-src trusty-proposed to get snapd 2.20 2. apt-get source snapd 3. cd ./snapd-2.20* 4. apt-get build-dep snapd 5. install libseccomp2 libseccomp-dev from trusty release (to demonstrate the problem) 6. debian/rules build # this should fail on amd64 ... FAIL: test_restrictions_working_args ... 7. install libseccomp2 libseccomp-dev from trusty-proposed 8. debian/rules clean ; debian/rules build # this should pass In addition, follow the testing procedures as outlined in bug #1450642 [Regression Potential] The patch to fix this issue required several other supporting patches. - This patches applied cleanly to trusty and the patches themselves are + These patches applied cleanly to trusty and the patches themselves are well tested under upstream and 16.04+. The regression potential should be relatively low since the testsuite during the build shows no errors or failures and snapd has a big testsuite. Manually testing with snaps and lxc (the biggest consumers of libseccomp) and running the libseccomp autopkgtests also shows no issues. = Original description = The snapd build on trusty for amd64 fails with the following error: """ make[2]: Entering directory `/tmp/snapd-2.20.1~14.04/cmd/snap-confine/tests' ... PASS: test_restrictions_working FAIL: test_restrictions_working_args """ (see https://launchpad.net/ubuntu/+source/snapd/2.20.1~14.04/+build/11759913) The same build works for i386 and armhf. I can reproduce this in a trusty chroot, upon further investigation it looks like the version of libseccomp (2.1.1) in trusty-proposed is the culprit. When I upgrade: """ Upgrade: libseccomp2:amd64 (2.1.1-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1), libseccomp-dev:amd64 (2.1.1-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1) """" all tests run fine. It looks like an issue with seccomp argument filtering (bpf) on 64 bit systems. This https://github.com/seccomp/libseccomp/releases/tag/v2.2.1 might include the missing fix, however I have not looked in detail what patch exactly we may need. Fwiw, we don't see this in spread because we build the package in the spread tests with `DEB_BUILD_OPTIONS='nocheck testkeys' dpkg- buildpackage` and we do not run the integration tests of snap-confine in anything else beside the package build (until https://github.com/snapcore/snapd/pull/2433/files is merged). ** Description changed: [Impact] - A latent bug in libseccomp 2.1.0 and the proposed 2.1.1-1ubuntu1~trusty1 was exposed in the snapd build testsuite when run on amd64. It has to do with libseccomp's state machine not always working correctly when using argument filtering and there were no tests for this particular failure in 2.1. Once 19e6c4aeca9818c4b288b09911dfa4be9a831236 (the upstream test for this issue) is applied to 2.1, you see the failures. Simple seccomp filters that just use the syscall name are not affected by the bug and we only use seccomp arg filtering in one interface which is why Tyler's testing of 2.1.1-1ubuntu1~trusty1 didn't show it either. The snap-confine tests do exercise it, but seccomp argument filtering wasn't added until series 16 and seccomp 2.2.3 had all the fixes already. Porting series 16 snapd/snap-confine and all of snap-confine's arg filtering tests to trusty revealed the bug in seccomp 2.1. + A latent bug in libseccomp 2.1.0 and the proposed 2.1.1-1ubuntu1~trusty1 was exposed in the snapd build testsuite when run on amd64. It has to do with libseccomp's state machine not always working correctly when using argument filtering and there were no tests for this particular failure in 2.1. Once 19e6c4aeca9818c4b288b09911dfa4be9a831236 (the upstream test for this issue) is applied to 2.1, you see the failures. Simple seccomp filters that just use the syscall name are not affected by the bug and we (currently) only use seccomp arg filtering in one interface which is why Tyler's testing of 2.1.1-1ubuntu1~trusty1 didn't show it either. The snap-confine tests do exercise it, but seccomp argument filtering wasn't added until series 16 and seccomp 2.2.3 had all the fixes already. Porting series 16 snapd/snap-confine and all of snap-confine's arg filtering tests to trusty revealed the bug in seccomp 2.1. [Test Case] A test case is included in the build in debian/patches/bpf-accumulator-check.patch (19e6c4aeca9818c4b288b09911dfa4be9a831236). You can check the amd64 build log to verify no failures. You can also run the snapd testsuite: 0. apt-get install dpkg-dev build-essential linux-libc-dev libseccomp-dev seccomp 1. enable deb-src trusty-proposed to get snapd 2.20 2. apt-get source snapd 3. cd ./snapd-2.20* 4. apt-get build-dep snapd 5. install libseccomp2 libseccomp-dev from trusty release (to demonstrate the problem) 6. debian/rules build # this should fail on amd64 ... FAIL: test_restrictions_working_args ... 7. install libseccomp2 libseccomp-dev from trusty-proposed 8. debian/rules clean ; debian/rules build # this should pass In addition, follow the testing procedures as outlined in bug #1450642 [Regression Potential] The patch to fix this issue required several other supporting patches. - These patches applied cleanly to trusty and the patches themselves are + This patches applied cleanly to trusty and the patches themselves are well tested under upstream and 16.04+. The regression potential should be relatively low since the testsuite during the build shows no errors or failures and snapd has a big testsuite. Manually testing with snaps and lxc (the biggest consumers of libseccomp) and running the libseccomp autopkgtests also shows no issues. = Original description = The snapd build on trusty for amd64 fails with the following error: """ make[2]: Entering directory `/tmp/snapd-2.20.1~14.04/cmd/snap-confine/tests' ... PASS: test_restrictions_working FAIL: test_restrictions_working_args """ (see https://launchpad.net/ubuntu/+source/snapd/2.20.1~14.04/+build/11759913) The same build works for i386 and armhf. I can reproduce this in a trusty chroot, upon further investigation it looks like the version of libseccomp (2.1.1) in trusty-proposed is the culprit. When I upgrade: """ Upgrade: libseccomp2:amd64 (2.1.1-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1), libseccomp-dev:amd64 (2.1.1-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1) """" all tests run fine. It looks like an issue with seccomp argument filtering (bpf) on 64 bit systems. This https://github.com/seccomp/libseccomp/releases/tag/v2.2.1 might include the missing fix, however I have not looked in detail what patch exactly we may need. Fwiw, we don't see this in spread because we build the package in the spread tests with `DEB_BUILD_OPTIONS='nocheck testkeys' dpkg- buildpackage` and we do not run the integration tests of snap-confine in anything else beside the package build (until https://github.com/snapcore/snapd/pull/2433/files is merged). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1653487 Title: seccomp argument filtering not working on trusty amd64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
