[Question] libseccomp runtime dependency #4540

sipasing · 2024-11-18T16:14:26Z

sipasing
Nov 18, 2024

Noob question, I see "Static Linking notices" on the releases page stating that libseccomp is a build-time dependency of runc, meaning that libseccomp-devel package should be installed on the system during runc build.

But what about runtime dependency ? I notice in Openela repo, runc spec having both a buildtime (BuildRequires tag) and a runtime (Requires tag) dependency on libseccomp. Can someone point me to the docs or explain why a runtime dependency for libseccomp is present.

Also Ques2) diving into build time dependency, how does this static linking take place ? Is there a library in libseccomp-devel package that runc is supposed to link against ?

Answered by cyphar

Nov 23, 2024

(This probably would've been better left as a discussion thread, but I'll answer here anyway.)

The binaries we build and ship on the releases page are statically linked, in order to make sure they work on any Linux system. There is no runtime dependency on libseccomp for those binaries because libseccomp is already embedded inside the binary.

However, distributions usually prefer shared linking (aka dynamic linking) where the binary has a reference to libseccomp.so that the link loader will load when the binary is executed. They usually prefer this because it (in theory) allows you to update the shared library with patches without having to rebuild every dependency, and improves memory us…

View full answer

cyphar · 2024-11-23T00:09:11Z

cyphar
Nov 23, 2024
Maintainer

(This probably would've been better left as a discussion thread, but I'll answer here anyway.)

The binaries we build and ship on the releases page are statically linked, in order to make sure they work on any Linux system. There is no runtime dependency on libseccomp for those binaries because libseccomp is already embedded inside the binary.

However, distributions usually prefer shared linking (aka dynamic linking) where the binary has a reference to libseccomp.so that the link loader will load when the binary is executed. They usually prefer this because it (in theory) allows you to update the shared library with patches without having to rebuild every dependency, and improves memory usage and disk space for very commonly used libraries. In that case, you need to have libseccomp.so installed at runtime, and this is a general property of shared libraries. You can see the list of shared libraries a dynamically linked binary depends on using ldd:

ldd examples

% ldd /usr/bin/runc
        linux-vdso.so.1 (0x00007faf37e3a000)
        libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007faf37dfd000)
        libc.so.6 => /lib64/libc.so.6 (0x00007faf36e00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007faf37e3c000)
% ldd /opt/google/chrome/chrome
        linux-vdso.so.1 (0x00007f850b226000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f850b204000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f850b1ff000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f850b19d000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f84fbeb2000)
        libnss3.so => /lib64/libnss3.so (0x00007f84fbd71000)
        libnssutil3.so => /lib64/libnssutil3.so (0x00007f850b166000)
        libsmime3.so => /lib64/libsmime3.so (0x00007f850b139000)
        libnspr4.so => /lib64/libnspr4.so (0x00007f850b0f7000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f84fbd1e000)
        libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f850b0cc000)
        libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f84fbcdf000)
        libcups.so.2 => /lib64/libcups.so.2 (0x00007f84fbc28000)
        libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f84fba35000)
        libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f84fba1d000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f84fb9f1000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f84fb906000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007f84fb7bf000)
        libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f84fb7ba000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f84fb7b5000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007f84fb7a0000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f84fb798000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f84fb78b000)
        libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f84fb767000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f84fb73b000)
        libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f84fb6f1000)
        libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f84fb686000)
        libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f84fb548000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007f84fb501000)
        libasound.so.2 => /lib64/libasound.so.2 (0x00007f84fb3f4000)
        libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f84fb3b8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f84fb38a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f84fb000000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f850b228000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007f84fb37f000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f84fb2d2000)
        libplc4.so => /lib64/libplc4.so (0x00007f84fb2cb000)
        libplds4.so => /lib64/libplds4.so (0x00007f84fb2c6000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f84faf16000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f84fb272000)
        libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007f84fb261000)
        libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007f84fb24e000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f84fac00000)
        libz.so.1 => /usr/lib64/zlib-ng-compat/libz.so.1 (0x00007f84fb22c000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f84fb225000)
        libmount.so.1 => /lib64/libmount.so.1 (0x00007f84faec9000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f84fae9a000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f84fb216000)
        libgallium-24.2.7.so => /lib64/libgallium-24.2.7.so (0x00007f84f8400000)
        libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f84fae84000)
        libxcb-randr.so.0 => /lib64/libxcb-randr.so.0 (0x00007f84fae72000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007f84fae6d000)
        libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f84fae4d000)
        libthai.so.0 => /lib64/libthai.so.0 (0x00007f84fae41000)
        libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f84f82e1000)
        libpng16.so.16 => /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.44.0 (0x00007f84fabb2000)
        libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f84fab63000)
        libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f84f8223000)
        libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f84fae32000)
        libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f84fae2d000)
        libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f84f81ab000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f84fae21000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00007f84f8197000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f84f80c8000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f84f80b0000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f84fab5d000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f84f80a1000)
        libjitterentropy.so.3 => /lib64/libjitterentropy.so.3 (0x00007f84f8097000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f84f7f0f000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f84f7eed000)
        libunistring.so.5 => /lib64/libunistring.so.5 (0x00007f84f7d04000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f84f7ced000)
        libhogweed.so.6 => /lib64/glibc-hwcaps/x86-64-v3/libhogweed.so.6.9 (0x00007f84f7ca2000)
        libnettle.so.8 => /lib64/glibc-hwcaps/x86-64-v3/libnettle.so.8.9 (0x00007f84f7c49000)
        libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f84f7ba2000)
        libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f84f7b66000)
        libglapi.so.0 => /lib64/libglapi.so.0 (0x00007f84f7b32000)
        libLLVM.so.19.1 => /lib64/libLLVM.so.19.1 (0x00007f84f0200000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f84f7b2d000)
        libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007f84f7b26000)
        libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007f84f7b20000)
        libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f84f7b16000)
        libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f84f7b0d000)
        libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007f84f7b08000)
        libdrm_radeon.so.1 => /lib64/libdrm_radeon.so.1 (0x00007f84f7af8000)
        libelf.so.1 => /lib64/libelf.so.1 (0x00007f84f7adc000)
        libdrm_amdgpu.so.1 => /lib64/libdrm_amdgpu.so.1 (0x00007f84f7acf000)
        libdrm_intel.so.1 => /lib64/libdrm_intel.so.1 (0x00007f84f7aa9000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f84f7aa2000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f84efe00000)
        libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f84f7a97000)
        libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f84f7a76000)
        libbz2.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbz2.so.1.0.6 (0x00007f84f7a5d000)
        libbrotlidec.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbrotlidec.so.1.1.0 (0x00007f84f7a4f000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f84f7a48000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f84f7a34000)
        libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.2.3 (0x00007f84ef800000)
        libeconf.so.0 => /lib64/libeconf.so.0 (0x00007f84f7a25000)
        libedit.so.0 => /lib64/libedit.so.0 (0x00007f84f79e9000)
        libzstd.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.1.5.6 (0x00007f84f014b000)
        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f84ef68d000)
        libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x00007f84f79db000)
        libbrotlicommon.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbrotlicommon.so.1.1.0 (0x00007f84f79b8000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f84f010f000)
        liblzma.so.5 => /lib64/glibc-hwcaps/x86-64-v3/liblzma.so.5.6.3 (0x00007f84f00d4000)

It is a little odd that they need to put an explicit Requires for libseccomp though -- rpm will automatically find all dynamic library dependencies and generate Requires automatically. This is how the openSUSE runc specfile works. I guess the specfile comes from RHEL, where they have a different policy on defining Requires.

How does this static linking take place ? Is there a library in libseccomp-devel package that runc is supposed to link against ?

Dynamic linking is done against libseccomp.so, static linking is done against libseccomp.a. Your distribution might not provide libseccomp.a (for instance, openSUSE only ships the .so for libseccomp).

For runc in particular, we build our own copy of libseccomp (see scripts/release_build.sh) and then do some hacks (see the static-bin rule in Makefile -- it's mainly -extldflags -static and -tags "netgo osusergo") to force Go to produce a static binary. Except in very specific circumstances, normally Go produces dynamically linked binaries.

0 replies

sipasing · 2024-11-25T06:12:40Z

sipasing
Nov 25, 2024
Author

(This probably would've been better left as a discussion thread, but I'll answer here anyway.)

Noted for next time.

6 replies

sipasing Nov 25, 2024
Author

Thanks for the detailed explanation above. Really Helpful.

I do have a related follow up.

How strict is the version dependency on libseccomp ? When there is a bump in dependent libseccomp version , the relevant files in code are updated like in this commit. cdccf6d
And I see the same bumped libseccomp version made available on the releases page in the Assets section.

But if i compare this to Open ELA code (say runc version 1.1.3) https://github.com/openela-main/runc/blob/60f3a7882c23095c06aab516e5567fd89efb7f1f/SPECS/runc.spec#L39, the version dependency is loose (> 2.5) instead of what i expected - that is slightly more strict dependency like >= 2.5.5 which would match code
I was wondering if this is a distro decision or something upstream code dictates/documents somewhere.

cyphar Nov 25, 2024
Maintainer

It depends if you're asking about versioning requirements for compiling runc or version compatibility for compiled (and dynamically linked) runc binaries.

For compiling runc, we have the same minimum version requirement as the libseccomp-golang package we use. At the moment, v0.10.0 has a minimum version requirement of libseccomp 2.3.1.

For compiled binaries, the compatibility guarantees are mostly up to the library. In libseccomp's case, as far as I know a binary compiled with an older libseccomp.so is expected to work with a newer libseccomp.so installed (most libraries are designed this way -- the only way this could break is if a newer libseccomp.so removed some exported symbols or broke the behaviour of some API).

Some libraries have mechanisms to allow you to use binaries built with a newer .so with older versions of the .so (usually this is done with symbol versioning, and is something libraries like glibc use -- but in practice it's difficult to compile binaries that work this way and so in general this feature doesn't really work). As far as I know, libseccomp doesn't use symbol versioning and thus doesn't have a way of explicitly providing this feature -- it might work in practice but there's no guarantee it will work.

When there is a bump in dependent libseccomp version , the relevant files in code are updated like in this commit. cdccf6d

This is done so that we can be sure what precise version of libseccomp we are building against, so we don't start having CI failures due to an update that we didn't notice.

And I see the same bumped libseccomp version made available on the releases page in the Assets section.

This is necessary because of the LGPL license that libseccomp uses -- we have to provide the same source code that runc was statically compiled against. This is another reason we pin a specific release of libseccomp in our build scripts -- we need to make sure we have the exact version that we built against so we can provide the correct source code.

I was wondering if this is a distro decision or something upstream code dictates/documents somewhere.

If they want to have stricter or looser version requirements, it's mostly a distro decision. But you probably can't build runc with a pre-2.3.1 version of seccomp because libseccomp-golang requires that version or newer. But I would expect most distributions to avoid using patch-version-level requirements unless necessary, since it increases specfile churn.

sipasing Nov 25, 2024
Author

Hmm. I was talking about compiled (and dynamically linked) runc binaries. But thanks for explaining both cases ( compiled and to-be-compiled).

Before this discussion, I used to think that compiled runc , at runtime, is dependent to a specific libseccomp version since I always saw the "Assets section" on the releases page here as a benchmark that distros would follow. But like u said, distributions tend to avoid using patch-version-level requirements due to specfile churn. Which kind of makes sense.

So the fact that the runc v1.1.3 built using this spec file, https://github.com/openela-main/runc/blob/60f3a7882c23095c06aab516e5567fd89efb7f1f/SPECS/runc.spec#L39, could link to shared libseccomp library available from libseccomp-2.5.1 or 2.5.2 or 2.5.3 or 2.5.4 or 2.5.5 depending on whats installed on the system at runtime (since anything >2.5 works) and even though the runc packaged in the Releases/Assets section uses libseccomp-2.5.5, both these scenarios (the open ELA spec and/or upstream runc Assets binary) would have no runtime behavioral difference with respect to runc.

cyphar Nov 25, 2024
Maintainer

Yup, that is correct, unless libseccomp has some backwards-compatibility breaking bug but that would be a problem with libseccomp not runc. In general, you should try to use the latest version of libseccomp you can because otherwise newer system call names won't be understood by libseccomp and you won't be able to write allow rules for them.

akhilerm Nov 26, 2024

For compiling runc, we have the same minimum version requirement as the libseccomp-golang package we use. At the moment, v0.10.0 has a minimum version requirement of libseccomp 2.3.1.

Does this mean that we can compile / link latest version of runc against a different version of seccomp (2.4.0 in my case) and expect no breakages?

I am trying to compile runc on photon3, which has libc 2.28 and libseccomp 2.4.0. Since the version was mentioned as 2.5, was confused whether runc depends on any specific features from that version. But AFAIU now, any version > 2.3.1 should work with runc while both compiling and running on the same version of libraries

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Question] libseccomp runtime dependency #4540

{{title}}

Replies: 2 comments 6 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

[Question] libseccomp runtime dependency #4540

sipasing Nov 18, 2024

Replies: 2 comments · 6 replies

cyphar Nov 23, 2024 Maintainer

sipasing Nov 25, 2024 Author

sipasing Nov 25, 2024 Author

cyphar Nov 25, 2024 Maintainer

sipasing Nov 25, 2024 Author

cyphar Nov 25, 2024 Maintainer

akhilerm Nov 26, 2024

sipasing
Nov 18, 2024

Replies: 2 comments 6 replies

cyphar
Nov 23, 2024
Maintainer

sipasing
Nov 25, 2024
Author

sipasing Nov 25, 2024
Author

cyphar Nov 25, 2024
Maintainer

sipasing Nov 25, 2024
Author

cyphar Nov 25, 2024
Maintainer