This bug was fixed in the package libseccomp - 2.1.1-1ubuntu1~trusty3
---------------
libseccomp (2.1.1-1ubuntu1~trusty3) trusty-proposed; urgency=medium
* Cherrypick various bpf fixes to support argument filtering on 64-bit
(LP: #1653487)
- debian/patches/bpf-use-state-arch.patch: use state->arch instead of
db->arch in _gen_bpf_arch()
- debian/patches/db-require-filters-to-share-endianess.patch: require all
filters in a collection to share the same endianess
- debian/patches/resolve-issues-caused-by-be.patch: resolve issues caused
by big endian systems
- debian/patches/bpf-accumulator-check.patch: test the bpf accumulator
checking logic
- debian/patches/bpf-track-accumulator-state.patch: track accumulator
state and reload it when necessary. This is the fix for LP: #1653487. The
previous patches are required by this patch.
- debian/patches/ensure-simulator-has-valid-arch.patch: ensure the
simulator always has a valid architecture value. This fixes a regression
in the testsuite introduced by resolve-issues-caused-by-be.patch
- debian/patches/bpf-accumulator-check-indep.patch: fix a regression in the
testsuite introduced by bpf-accumulator-check.patch
- debian/patches/fix-audit-arch-i386.patch: fix arch token for 32-bit x86
not being defined correctly for the tools
libseccomp (2.1.1-1ubuntu1~trusty1) trusty-proposed; urgency=medium
* Bring libseccomp 2.1.1-1ubuntu1~vivid2, from Ubuntu 14.10, to Ubuntu
14.04 and add a couple patches to account for new syscalls found in the
4.4 based hardware enablement kernel. This allows for proper snap seccomp
confinement on Ubuntu 14.04 when using the hardware enablement kernel
(LP: #1450642)
- debian/patches/add-membarrier-and-userfaultfd.patch: Add membarrier and
userfaultfd syscalls
- debian/patches/add-mlock2.patch: Add mlock2 syscall
- debian/tests/data/all-except-s390-4.4.filter: Add autopkgtest that
verifies all syscalls found in the 4.4 kernel, except for the s390
specific syscalls, are supported by libseccomp. The s390 specific
syscalls are not needed since this version of libseccomp does not
support the s390 architecture.
- debian/tests/test-filter: Skip the getrandom filter tests since
SYS_getrandom is not defined in 14.04 environment and the getrandom(2)
syscall is not even available in the 14.04 release kernel.
libseccomp (2.1.1-1ubuntu1~vivid2) vivid-proposed; urgency=medium
* add-finit-module.patch: add finit_module syscalls to x86 and x86-64
syscall tables
* update syscalls for modern kernels (skipping MIPS)
- update syscalls for 3.16:
+ update-x86-syscall-table.patch
+ update-x86_64-syscall-table.patch
+ update-arm-syscall-table.patch
+ update-x32-syscall-table.patch
+ sync-syscall-table-entries.patch
+ sync-syscall-table-entries-fixtypo.patch
- update syscalls for 3.17:
+ sync-syscall-table-entries-3.17.patch
- update syscalls for 3.19:
+ sync-syscall-table-entries-3.19.patch
- LP: #1450642
* fix-segfault-with-unknown.patch: fix segfault when find unknown syscall
* debian/patches/add-missing-arm-private-syscalls.path: add missing private
ARM syscalls
* add autopkgtests for scmp_sys_resolver and filter testing and
SYS_getrandom() testing
libseccomp (2.1.1-1) unstable; urgency=low
* New upstream release (Closes: 733293).
* copyright: add a few missed people.
* rules: adjusted for new test target.
* libseccomp2.symbols: drop accidentally exported functions.
* control:
- bump standards, no changes needed.
- add armel target
-- Jamie Strandboge <[email protected]> Wed, 04 Jan 2017 21:11:30 +0000
** Changed in: libseccomp (Ubuntu Trusty)
Status: Fix Committed => Fix Released
--
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/1653487
Title:
seccomp argument filtering not working on trusty amd64
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Trusty:
Fix Released
Bug description:
[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 (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.
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).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
