A bit of history. EXTRA_BUILDTAGS was introduced in commit dac417174,
as a quick way to add some extra Go build tags to the runc build.
Later, commit 767bc008 changed Makefile to not get EXTRA_TAGS from the
shell environment, as the name is quite generic and some unrelated
environment variable with that name can affect runc build. While such
change does make sense, it makes it more complicated to pass build tags
in CI and otherwise (see e.g. commit 0e1fe368a).
Moreover, runc build uses some Go build tags by default (via Makefile),
and while it is easy to add more build tags (via EXTRA_BUILDTAGS), in
order to remove some existing tags one has to redefine BUILDTAGS from
scratch, which is not very convenient (again, see commit 0e1fe368a which
gets the current value of BUILDTAGS from the Makefile in order to remove
a single tag).
To handle all of the above, let's do this:
- implement RUNC_BUILDTAGS, fixing the issue of not-so-unique name;
- allow to get RUNC_BUILDTAGS from shell environment;
- implement a feature to remove a build tag from default set by
prefixing it with "-" (as in RUNC_BUILDTAGS="-seccomp");
- document all this in README;
- make CI use the new feature;
- keep EXTRA_BUILDTAGS for backward compatibility, add a make warning
and a TODO to remove it for runc 1.6.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This adds support for WaitKillableRecv seccomp flag
(also known as SCMP_FLTATR_CTL_WAITKILL in libseccomp and
as SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV in the kernel).
This requires:
- libseccomp >= 2.6.0
- libseccomp-golang >= 0.11.0
- linux kernel >= 5.19
Note that this flag does not make sense without NEW_LISTENER, and
the kernel returns EINVAL when SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV
is set but SECCOMP_FILTER_FLAG_NEW_LISTENER is not set.
For runc this means that .linux.seccomp.listenerPath should also be set,
and some of the seccomp rules should have SCMP_ACT_NOTIFY action. This
is why the flag is tested separately in seccomp-notify.bats.
At the moment the only adequate CI environment for this functionality is
Fedora 43. On all other platforms (including CentOS 10 and Ubuntu 24.04)
it is skipped similar to this:
> ok 251 runc run [seccomp] (SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV) # skip requires libseccomp >= 2.6.0 and API level >= 7 (current version: 2.5.6, API level: 6)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Found out that these changes were backported to release-1.4 (PR 5040)
and made its way into runc v1.4.0, but were missing from its CHANGELOG.
Move the item to v1.4.0 changelog, and add a backport PR reference.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Aleksa Sarai (4):
VERSION: back to development
VERSION: release v1.5.0-rc.1
CHANGELOG: forward-port v1.4.1 entry
CHANGELOG: add original PR references to backports
LGTMs: rata lifubang
Some of the patches in the "unreleased" section were backported and so
they can be moved to the v1.4.1 section to some unneeded avoid
duplication.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
When going through the changelog for v1.5.0-rc.1, these PRs were merged
but not referenced by their original PR number in the changelog, making
it harder to figure out which patches since v1.4.0-rc.1 are in
v1.5.0-rc.1 or v1.4.0.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Commit 192e3d416f ("ci: add conmon tests run") was merged without
rebasing on top of commit e2c989b7e1 ("build: enable libpathrs by
default"), causing build failures when it was merged.
The solution is to just use the same install script as the rest of CI
from commit 7322b05f41 ("ci: build and install libpathrs").
Fixes: 192e3d416f ("ci: add conmon tests run")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Aleksa Sarai (11):
gha: test both with and without libpathrs
build: enable libpathrs by default
ci: build and install libpathrs
build: enable builds with libpathrs
deps: update to cyphar.com/go-pathrs@v0.2.4
README: document libpathrs build tag
script: seccomp.sh -> build-seccomp.sh
build: rename /opt/libseccomp cdylib directory
build: treat armhf as ARMv7
dockerfile: switch to Debian 13
integration: output debug information in fd leak test
LGTMs: rata kolyshkin AkihiroSuda
This entry was added by commit 653161f6d8 ("docs/spec-conformance.md:
update for spec v1.3.0") but the spec was updated before the v1.3.0
release to remove this requirement for poststart hooks in order to match
runc's current behaviour.
Fixes: 653161f6d8 ("docs/spec-conformance.md: update for spec v1.3.0")
Ref: opencontainers/runtime-spec#1262
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
We do plan to make libpathrs required in the future, but in the meantime
we should test both with and without libpathrs in our CI to catch
regressions for users that will not use libpathrs initially.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
libpathrs has better hardening against certain attacks (most notably on
older kernels) so we should use it by default. This opens the door to
us using cyphar.com/go-pathrs in the future in order to remove some of
our internal/pathrs wrappers (that reimplement bits of libpathrs).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
pathrs-lite supports transparently switching to libpathrs.so as the
backend with the "libpathrs" build tag. In order to make this work
properly with our CI and release build scripts, we we need to have a
similar setup as with we do with libseccomp.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Ever since v0.6.0 of github.com/cyphar/filepath-securejoin, pathrs-lite
has been able to transparently switch to using libpathrs as the backend
for safe path resolution (at compile-time, using a build tag). Note that
because build-tags apply globally, this allows for us to easily opt
pure-Go dependencies into all using libpathrs as well for our binaries.
In a future patch this will likely be enabled by default, but document
that this is an option for downstreams that want to opt-in to using
libpathrs.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
The intention of commit 531e29e192 ("script/lib.sh: set GOARM=5 for
armel, GOARM=6 for armhf") was to properly support older ARM platforms
with our release builds.
However, we have never been able to support ARMv6 for our builds because
we use the Debian compiler to build the libseccomp we statically compile
into our binaries and (as per the now-deleted comment itself) Debian
treats armhf as being ARMv7 so the final binaries we produced were
always only ever compatible with ARMv7+.
This was a bit of an oddity before but when building libpathrs for
releases we will need to use Rust which makes the target more explicit
(and while it does support armhf, we are using the Debian-packaged Rust
cross-compiler and thus are in the same dilemma with what Debian
considers "armhf" to be).
All-in-all, it's better to just bite the bullet and just follow Debian
here properly.
Fixes: 531e29e192 ("script/lib.sh: set GOARM=5 for armel, GOARM=6 for armhf")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Debian 13 (trixie) was released a few months ago and it's probably
prudent to just upgrade. This is also necessary to get access to riscv64
repositories when we build libpathrs for inclusion in our runc binaries.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
When deprecating Relabel field, its json attributes were mistakenly
removed, so now it is:
- saved to JSON under "Relabel" (rather than "relabel");
- won't be ignored if empty.
Let's fix it before it's too late.
Fixes: 8b2b5e94 ("libct: remove relabeling dead code")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
It makes more sense to save whether we should cleanup the directory
after it gets created (to avoid error cases deleting a different
directory) as well as tying this check to the existing os.ErrExist
check rather than doing an extra stat(2).
Fixes: e2baa3ad10 ("Intel RDT: update according to spec changes.")
Suggested-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This fixes random failures to start a container in conmon integration
tests (see issue 5151).
I guess we need to find another way to fix issue 4645.
This reverts commit 1b39997e73.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is no way to set Mount.Relabel field via OCI spec (config.json),
and so the relabeling code is never used.
My guess it's a leftover from times when runc used to be part of Docker.
Remove it, and mark Relabel field as deprecated.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is one proposed clarification to the OCI spec: the subdirectory
needs to be deleted. Runc already does that, but the clarification adds
for directory removal only if the directory was created by us.
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
unix.CPUSet is limited to 1024 CPUs. Calling
unix.SchedSetaffinity(pid, cpuset) removes all CPUs starting from 1024
from allowed CPUs of pid, even if cpuset is all ones. As a
consequence, when runc tries to reset CPU affinity to "allow all" by
default, it prevents all containers from CPUs 1024 onwards.
This change uses a huge CPU mask to play safe and get all possible
CPUs enabled with a single sched_setaffinity call.
Fixes: #5023
Signed-off-by: Antti Kervinen <antti.kervinen@intel.com>
Some maintainers appear to have removed their PGP keys, which causes
"gpg --import" during "make validate-keyring" to fail. The solution is
to switch to a non-fatal warning if no keys were imported.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was a really ugly hack to try to reduce the impact of our original
set of CVE-2019-5736 mitigations, but unfortunately had too many caveats
to its use to ever be really useful. In addition, it was completely
obsoleted by the migration to using an detached overlayfs mount in
commit 515f09f7b1 ("dmz: use overlayfs to write-protect /proc/self/exe
if possible").
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These were all marked deprecated in commit a75076b4a4 ("Switch to
opencontainers/cgroups") when we switched maintenance of our cgroup code
to opencontainers/cgroups.
Users have had ample time to switch to opencontainers/cgroups
themselves, so we can finally remove this.
Note that the whole libcontainer/devices package will be moved to
moby/sys in the near future, so this whole package will be marked
deprecated soon.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These were inadvertently added to our exported APIs by commit
eeda7bdf80cca ("Add memory policy support"). We couldn't remove them
from runc 1.4.x, but we deprecated them in commit 3741f9186d
("libct/configs: mark MPOL_* constants as deprecated") and marked them
for removal in runc 1.5. Users should never have used these in the first
place.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Kir Kolyshkin