[DO NOT MERGE] make sure containerd runs with all libseccomp versions

[thaJeztah]

This is just to discuss the issue, and to discuss possible approaches

libseccomp-golang seccomp/libseccomp-golang@9814e55a
started using a new seccomp_version API, which was introduced in libseccomp 2.3
(addded in seccomp/libseccomp@58a7c20). As a result,
if the binary is compiled with libseccomp 2.3 or up, the minimum requirement for
libseccomp to run the binary will also be libseccomp 2.3.0 (running on a system
with an older version of libseccomp, will produce "undefined symbol: seccomp_version")

A seccond problem also came up; if the binary is compiled with libseccomp 2.4.0
or up, containerd can only be run with that version (caused by seccomp/libseccomp@e89d182), and machines running libseccomp
2.3 or 2.2 will fail with:

there's an error: /usr/bin/containerd: undefined symbol: seccomp_api_get

The latest containerd has been compiled with libseccomp 2.4.x, and therefore can
only be used on a system that has libseccomp 2.4.

Current libseccomp 2.4.1 is known to have performance issues (due to a refactor),
see seccomp/libseccomp#153 for more details on that.

This PR restricts the version of libseccomp-dev at compile time to 2.2.x, so
that the new API isn't used, and that the binary is compatible with libseccomp
2.2.0 and up.

The .deb binaries all look to be compiled with ubuntu:bionic.

note that the base image to build binaries for all .deb packages is currently
ubuntu:bionic, irregardless of the target distro version of the package)

Checking what's currently available:

Ubuntu

docker run --rm ubuntu:xenial sh -c 'apt-get update -qq && apt-cache madison libseccomp-dev'
libseccomp-dev | 2.4.1-0ubuntu0.16.04.2 | http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
libseccomp-dev | 2.4.1-0ubuntu0.16.04.2 | http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
libseccomp-dev | 2.2.3-3ubuntu3 | http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

docker run --rm ubuntu:bionic sh -c 'apt-get update -qq && apt-cache madison libseccomp-dev'
libseccomp-dev | 2.4.1-0ubuntu0.18.04.2 | http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
libseccomp-dev | 2.4.1-0ubuntu0.18.04.2 | http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
libseccomp-dev | 2.3.1-2.1ubuntu4 | http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Debian

docker run --rm debian:stretch sh -c 'apt-get update -qq && apt-cache madison libseccomp-dev'
libseccomp-dev | 2.3.1-2.1+deb9u1 | http://deb.debian.org/debian stretch/main amd64 Packages

docker run --rm debian:buster sh -c 'apt-get update -qq && apt-cache madison libseccomp-dev'
libseccomp-dev |    2.3.3-4 | http://deb.debian.org/debian buster/main amd64 Packages

RHEL/CentOS

Note that RHEL 8 and CentOS 8 no longer have libseccomp-devel in the default repositories;
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index

The following packages are distributed in the Base channel of RHEL 7 and in RHEL 8 they are a part of the CodeReady Linux Builder repository:

...

• libseccomp-devel

The "CodeReady Linux Builder" is for RHEL; the CentOS equivalent for that is the PowerTools repo

docker run --rm centos:7 sh -c 'yum --showduplicates list libseccomp-devel'
Available Packages
libseccomp-devel.i686                       2.3.1-3.el7                     base
libseccomp-devel.x86_64                     2.3.1-3.el7                     base

docker run --rm centos:8 sh -c 'yum --enablerepo=PowerTools --showduplicates list libseccomp-devel'

Available Packages
libseccomp-devel.i686                    2.3.3-3.el8                  PowerTools
libseccomp-devel.x86_64                  2.3.3-3.el8                  PowerTools

Amazon Linux

docker run --rm amazonlinux:2 sh -c 'yum --showduplicates list libseccomp-devel'
Available Packages
libseccomp-devel.x86_64               2.3.1-3.amzn2.0.1               amzn2-core
libseccomp-devel.x86_64               2.3.1-3.amzn2.0.3               amzn2-core

SUSE

docker run --rm opensuse/leap:15 sh -c 'zypper search -s libseccomp-devel'

S | Name             | Type    | Version           | Arch   | Repository
--+------------------+---------+-------------------+--------+-----------------------
  | libseccomp-devel | package | 2.4.1-lp151.3.3.1 | x86_64 | Main Update Repository
  | libseccomp-devel | package | 2.3.2-lp151.2.3   | x86_64 | Main Repository
  | libseccomp-devel | package | 2.4.1-lp151.3.3.1 | i586   | Main Update Repository

Signed-off-by: Sebastiaan van Stijn github@gone.nl

[thaJeztah]

Based on the above; most distros no longer have libseccomp 2.2, but the minimum version is 2.3 (and with the performance regression) should be something we want to support.

I don't know if there's features we would be missing if we compile against 2.3, that would be available with 2.4

Also not sure if there's a way to get older versions (2.2) to use in our build pipeline (which would allow users to run with anything libseccomp >= 2.2.0

If we do require libseccomp 2.3 (or 2.4), we should at least set the correct Requires for our packages.

[thaJeztah]

ping @seemethere @justincormack @crosbymichael @xinfengliu PTAL

[thaJeztah]

@seemethere wondering; would compiling the packages for each distro separately (instead of trying to optimise by re-using builds) be a big blocker? I'm wondering how much time we save by doing this (at the cost of possibly building incompatible packages?). Basically thinking to always use a base/build-image that matches the actual target

[crosbymichael]

We should probably still target 2.4, even with the performance regression because of CVEs that are not backported to 2.3

[thaJeztah]

Ah, hm, yes. That's definitely unfortunate.

I also tried downgrading to 2.2 on a machine, but that uninstalls docker-ce and containerd.io (probably because of requires in the package), so that combination definitely won't work

[seemethere]

We do build for each distro with this repo

[seemethere]

These are no longer one size fits all packages starting with 1.2.10

[justincormack]

All Ubuntu versions 18.04, 18.10 and 19.04 now have libseccomp 2.4.x installed, even though these must have shipped with 2.3 or earlier as 2.4 was only released in March. Given that this is ABI incompatible this is really problematic. Debian doesn't seem to update (hopefully they patch). I think the only workable solution (ish) is to build individually per distro, and potentially deal with future Ubuntu breakages (assuming everyone has updated).

I think we can't deal with the performance issue ourselves, if upstream and the distro have shipped a slow version we can't fix that.

Because of the ABI issues and the lack of clarity around what is being backported, I don't think its very safe to build with a common version for all distros at all.

[thaJeztah]

I don't think its very safe to build with a common version for all distros at all.

Yes, agreed. @seemethere indicated above that we no longer do that. I'm trying to figure out how we actually build it though; the Jenkinsfile only shows image based builds, but there's only ubuntu:bionic in there, no ubuntu:xenial;

containerd-packaging/Jenkinsfile

Line 7 in dcd6c95

[image: "ubuntu:bionic", arches: arches],

Perhaps @seemethere could help me there to understand how it works 😅 😊 (I don't understand LOL)

(edit: updated link to actually point to the right file)

[seemethere]

@thaJeztah These are all of the things we build for:

https://github.com/docker/release-packaging/blob/containerd/Jenkinsfile#L6-L23

This repository contains a subset of that because the original intention was to make this open source. 🤷‍♂

[thaJeztah]

Right; but looks like it's currently not actually matching the list of CE distros. Let's update that so that CI tests the actual list and we can detect failures before merging changes (and add a comment that the actual list we're building is overridden in another repo)