Skip to content

Use buster backports to build with libseccomp-2.4.4#42054

Merged
AkihiroSuda merged 1 commit intomoby:masterfrom
jhuntwork:41704-update-libseccomp
Mar 14, 2021
Merged

Use buster backports to build with libseccomp-2.4.4#42054
AkihiroSuda merged 1 commit intomoby:masterfrom
jhuntwork:41704-update-libseccomp

Conversation

@jhuntwork
Copy link
Copy Markdown
Contributor

@jhuntwork jhuntwork commented Feb 22, 2021

Fixes #41704

The latest released versions of the static binaries (20.10.3) are still unable
to use faccessat2 with musl-1.2.2 even though this was addressed in #41353 and
related issues. The underlying cause seems to be that the build system
here still uses the default version of libseccomp shipped with buster.
An updated version is available in buster backports:
https://packages.debian.org/buster-backports/libseccomp-dev

Signed-off-by: Jeremy Huntwork [email protected]

- What I did

Built dockerd, containerd and runc locally and then compared the results with previous ones.

- How I did it

My original running system used the 20.10.3 published static binaries:

$ docker version
Client: Docker Engine - Community
 Version:           20.10.3
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        48d30b5
 Built:             Fri Jan 29 14:28:23 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.3
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       46229ca
  Built:            Fri Jan 29 14:31:57 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
$ runc --version
runc version 1.0.0-rc92
commit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
spec: 1.0.2-dev

Prepare a test file that will use the faccessat2 syscall:

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(void)
{
    int r;
    r = faccessat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY, AT_EACCESS);
    printf("Returned %d\n", r);
    return r;
}

Run a container using musl-1.2.2, build it and execute it:

$ docker run -it -v "$(pwd)":/src mere/dev
# pacman -Q musl
musl 1.2.2-1
# cc test.c -o test -static
# file test
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
# ./test
Returned -1

Running with strace would also give something like this:

faccessat2(AT_FDCWD, "/etc/resolv.conf", F_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)

- How to verify it

Build locally with this change, I simply ran 'make' and 'make install'

Afterwards, the docker and runc version reported this:

$ docker version
Client:
 Version:           20.10.0-dev
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        70a00157f1
 Built:             Mon Feb 22 04:15:30 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          dev
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       bc6f4cc703
  Built:            Mon Feb 22 03:36:24 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
$ runc --version
runc version 1.0.0-rc93
commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
spec: 1.0.2-dev
go: go1.13.15
libseccomp: 2.4.4

And testing the statically compiled C file running in the same container now works:

$ docker run -it -v "$(pwd)":/src mere/dev
# ./test
Returned 0

- Description for the changelog

Build static binaries with libseccomp-2.4.4

- A picture of a cute animal (not mandatory but encouraged)
image

@jhuntwork jhuntwork force-pushed the 41704-update-libseccomp branch from d457216 to 72cbb51 Compare February 22, 2021 05:29
@jhuntwork
Copy link
Copy Markdown
Contributor Author

jhuntwork commented Feb 22, 2021

Looks like the rootless dev image build failed. There's obviously something about the build system I'm not fully understanding yet.

[2021-02-22T05:30:54.581Z] #53 12.01 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libseccomp.a(libseccomp_la-api.o): in function `seccomp_api_get':

[2021-02-22T05:30:54.581Z] #53 12.01 (.text+0x10): multiple definition of `seccomp_api_get'; /tmp/go-link-061029346/000020.o:/tmp/tmp.QZjEB1jivx/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:150: first defined here

@jhuntwork
Copy link
Copy Markdown
Contributor Author

jhuntwork commented Feb 22, 2021

Looking at #42056, I see it includes some similar fixes namely moby/buildkit#1955 which also uses the buster backports. I suspect that I may have submitted this pull request in the wrong place? Any thoughts on what needs to be done to get the amd64 Linux static binaries built against a newer version of libseccomp?

@thaJeztah
Copy link
Copy Markdown
Member

thaJeztah commented Mar 10, 2021

I copied the full failure;

#53 [runc 1/1] RUN --mount=type=cache,target=/root/.cache/go-build     --mount=type=cache,target=/go/pkg/mod     --mount=type=bind,src=hack/dockerfile/install,target=/tmp/install         PREFIX=/build /tmp/install/install.sh runc
#53 sha256:f3af8dea88f5099d7a5b9408f3b11cf3b8bb8413732fa53c0c4446a1ca777529
#53 6.313 + cd /tmp/tmp.6DDJh7PKrT/src/github.com/opencontainers/runc
#53 6.313 + git checkout -q 12644e614e25b05da6fd08a38ffa0cfe1903fdec
#53 6.544 + '[' -z '' ']'
#53 6.544 + target=static
#53 6.544 + make 'BUILDTAGS=seccomp ' static
#53 6.991 CGO_ENABLED=1 go build -trimpath   -tags "seccomp  netgo osusergo" -ldflags "-w -extldflags -static -X main.gitCommit="12644e614e25b05da6fd08a38ffa0cfe1903fdec" -X main.version=1.0.0-rc93 " -o runc .
#53 12.01 # github.com/opencontainers/runc
#53 12.01 /usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
#53 12.01 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libseccomp.a(libseccomp_la-api.o): in function `seccomp_api_get':
#53 12.01 (.text+0x10): multiple definition of `seccomp_api_get'; /tmp/go-link-061029346/000020.o:/tmp/tmp.QZjEB1jivx/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:150: first defined here
#53 12.01 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libseccomp.a(libseccomp_la-api.o): in function `seccomp_api_set':
#53 12.01 (.text+0x80): multiple definition of `seccomp_api_set'; /tmp/go-link-061029346/000020.o:/tmp/tmp.QZjEB1jivx/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:155: first defined here
#53 12.01 collect2: error: ld returned 1 exit status
#53 12.01
#53 12.01 make: *** [Makefile:42: static] Error 2
#53 ERROR: executor failed running [/bin/sh -c PREFIX=/build /tmp/install/install.sh runc]: exit code: 2

I'm wondering if its because of the cache mounts that are used;

moby/Dockerfile

Lines 217 to 220 in 083dbe9

RUN --mount=type=cache,target=/root/.cache/go-build \
--mount=type=cache,target=/go/pkg/mod \
--mount=type=bind,src=hack/dockerfile/install,target=/tmp/install \
PREFIX=/build /tmp/install/install.sh runc

I recall Go builds with CGO not invalidating cache if there's changes in C code (see, e.g. golang/go#25419 and golang/go#19883).

Currently, the cache-mount does not specify a ID, which means the cache can be shared between stages. Perhaps we need to add an ID to prevent runc trying to reuse the cache from other stages that also have a cache for /root/.cache/go-build see the Dockerfile syntax

@thaJeztah
Copy link
Copy Markdown
Member

thaJeztah commented Mar 10, 2021

Let me restart the build as well, to see if rootless passes

thaJeztah
thaJeztah reviewed Mar 10, 2021
View reviewed changes
Comment thread Dockerfile Outdated
Comment thread Dockerfile Outdated
@thaJeztah thaJeztah added this to the 21.xx milestone Mar 10, 2021
@thaJeztah
Copy link
Copy Markdown
Member

thaJeztah commented Mar 10, 2021

I suspect that I may have submitted this pull request in the wrong place? Any thoughts on what needs to be done to get the amd64 Linux static binaries built against a newer version of libseccomp?

This is the right place (perhaps both places are needed); this Dockerfile is used currently to build the static binaries of docker that are published on https://download.docker.com/linux/static/stable/. I marked the PR for cherry-picking (it needs to be backported to the 20.10 release branch to be used for that release)

@jhuntwork jhuntwork force-pushed the 41704-update-libseccomp branch from f213d4e to 35ed2b4 Compare March 10, 2021 15:00
@jhuntwork
Use buster backports to build with libseccomp-2.4.4
1600e85 
Fixes moby#41704

The latest released versions of the static binaries (20.10.3) are still unable
to use faccessat2 with musl-1.2.2 even though this was addressed in moby#41353 and
related issues. The underlying cause seems to be that the build system
here still uses the default version of libseccomp shipped with buster.
An updated version is available in buster backports:
https://packages.debian.org/buster-backports/libseccomp-dev

Signed-off-by: Jeremy Huntwork <[email protected]>
@jhuntwork jhuntwork force-pushed the 41704-update-libseccomp branch from 35ed2b4 to 1600e85 Compare March 10, 2021 15:01
thaJeztah
thaJeztah approved these changes Mar 14, 2021
View reviewed changes
Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Copy Markdown
Member

thaJeztah commented Mar 14, 2021

@tonistiigi @AkihiroSuda @tiborvass PTAL

@AkihiroSuda AkihiroSuda merged commit 4735a0c into moby:master Mar 14, 2021
@thaJeztah thaJeztah mentioned this pull request Mar 15, 2021
Merged
@thaJeztah thaJeztah mentioned this pull request Mar 16, 2021
Closed
jhuntwork added a commit to jhuntwork/merelinux that referenced this pull request Apr 11, 2021
@jhuntwork
Improvements to build scripts and containers
eb04933 
- Updates to recent versions of packages from the testing channel
- Makes `scripts/build.sh` slightly more portable. For example, pending
  release of the next version of docker with fixes like
  [this one](moby/moby#42054), it should be
  possible to build mere packages on Mac hosts.
- Use a non-privileged user in the container and map that user to the
  uid and gid of the host system user so that created files in the
  mounted volumes will be owned by the host user.
@jhuntwork jhuntwork mentioned this pull request Apr 11, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@thaJeztah thaJeztah thaJeztah approved these changes

@AkihiroSuda AkihiroSuda AkihiroSuda approved these changes

Assignees

No one assigned

Labels

area/packaging area/security/seccomp process/cherry-picked status/2-code-review

Projects

None yet

Milestone

23.0.0

Development

Successfully merging this pull request may close these issues.

Directory not writeable

3 participants

@jhuntwork @thaJeztah @AkihiroSuda