In linux 5.14 and hopefully some backports, core scheduling allows processes to
be co scheduled within the same domain on SMT enabled systems.
The containerd impl sets the core sched domain when launching a shim. This
allows a clean way for each shim(container/pod) to be in its own domain and any
additional containers, (v2 pods) be be launched with the same domain as well as
any exec'd process added to the container.
kernel docs: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/core-scheduling.html
Signed-off-by: Michael Crosby <michael@thepasture.io>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This brings in some cri api changes for cgroups, Windows pod sandbox security
context changes and some new fields for the Windows version of a privileged
container.
This also unfortunately bumps the prometheus client, grpc middleware, bolt
and klog :(
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
systemd uses SIGRTMIN+n signals, but containerd didn't support the signals
since Go's sys/unix doesn't support them.
This change introduces SIGRTMIN+n handling by utilizing moby/sys/signal.
Fixes#5402.
https://www.freedesktop.org/software/systemd/man/systemd.html#Signals
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
This package as recently updated to add support for Linux on
32-bit PowerPC (ppc), implemented by gccgo.
Signed-off-by: Ben Hutchings <ben.hutchings@essensium.com>
full diff: https://github.com/containerd/consolve/compare/v1.0.0...v1.0.1
vendor golang.org/x/sys 2334cc1a136f0a5b4384f1a27e3634457be08553
full diff: ed371f2e16...2334cc1a13
- unix: add Darwin support for clonefile syscalls
- Adds openat2 for linux
openat2 is a new syscall added to Linux 5.6. It provides a superset of
openat(2) functionality, extending it with flags telling the kernel how
to resolve the paths.
For more info, see https://lwn.net/Articles/803237/
NOTE that this is a second attempt to add the call; the previous one
(https://golang.org/cl/227280) was reverted
(https://golang.org/cl/227846) due to the test case failure on ARM
(https://golang.org/issue/38357).
This CL has the test case reworked to be less assumptive to the testing
environment. In particular, it first tries if the most simplistic
openat2() call succeeds, and skips the test otherwise. It is done that
way because CI can be under under different kernels and in various
envrionments -- in particular, Docker+seccomp can result in EPERM from a
system call (which is not expected otherwise).
For previous discussions about the test case, see
https://golang.org/cl/227865.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: f3200d17e0...ab34263943
Worth mentioning that there's a comment updated in golang.org/x/net/websocket:
This package currently lacks some features found in alternative
and more actively maintained WebSocket packages:
https://godoc.org/github.com/gorilla/websockethttps://godoc.org/nhooyr.io/websocket
It's used in k8s.io/apiserver/pkg/util/wsstream/stream.go, so perhaps that should
be reviewed if the alternatives are better for how it's used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: 60c769a6c5...69ecbb4d6d
Includes 69ecbb4d6d
(forward-port of 8b5121be2f),
to address CVE-2020-7919:
Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
functions of golang.org/x/crypto/cryptobyte can lead to a panic.
The malformed certificate can be delivered via a crypto/tls connection to a
client, or to a server that accepts client certificates. net/http clients can
be made to crash by an HTTPS server, while net/http servers that accept client
certificates will recover the panic and are unaffected.
Thanks to Project Wycheproof for providing the test cases that led to the
discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
List generated by running:
`git diff c9d45e652619589b4bf9 vendor.conf`
in the containerd/cri repositoru
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This prepares us to be able to update docker/docker vendoring to a
recent commit.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
This change includes a cri master bump and a cgroup bump for windows support
with cgroup stats and reusing the cgroup metric types.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
We are separating out the encryption code and have designed a few new
interfaces and APIs for processing content streams. This keep the core
clean of encryption code but enables not only encryption but support of
multiple content types ( custom media types ).
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Includes 6635b4f0c6,
which fixes a vulnerability in runc that allows a container escape (CVE-2019-5736)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: John Howard <jhoward@microsoft.com>
Allows containerd.exe to run as a Windows service. eg
Register: `.\containerd.exe --register-service`
Start: `net start containerd`
...
Stop: `net stop containerd`
Unregister: `.\containerd.exe --unregister-service`
When running as a service, logs will go to the Windows application
event log.
This seems to pickup a bunch of *.c files and some other changes which follow
from having included some new packages because of that.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This version includes "x/net/context" which is fully compatible with
the standard Go "context" package, so the two can be mixed together.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
With this changeset we introduce several new things. The first is the
top-level dist command. This is a toolkit that implements various
distribution primitives, such as fetching, unpacking and ingesting.
The first component to this is a simple `fetch` command. It is a
low-level command that takes a "remote", identified by a `locator`, and
an object identifier. Keyed by the locator, this tool can identify a
remote implementation to fetch the content and write it back to standard
out. By allowing this to be the unit of pluggability in fetching
content, we can have quite a bit of flexibility in how we retrieve
images.
The current `fetch` implementation provides anonymous access to docker
hub images, through the namespace `docker.io`. As an example, one can
fetch the manifest for `redis` with the following command:
```
$ ./dist fetch docker.io/library/redis latest mediatype:application/vnd.docker.distribution.manifest.v2+json
```
Note that we have provided a mediatype "hint", nudging the fetch
implementation to grab the correct endpoint. We can hash the output of
that to fetch the same content by digest:
```
$ ./dist fetch docker.io/library/redis sha256:$(./dist fetch docker.io/library/redis latest mediatype:application/vnd.docker.distribution.manifest.v2+json | shasum -a256)
```
Note that the hint is now elided, since we have affixed the content to a
particular hash.
If you are not yet entertained, let's bring `jq` and `xargs` into the
mix for maximum fun. The following incantation fetches the same manifest
and downloads all layers into the convenience of `/dev/null`:
```
$ ./dist fetch docker.io/library/redis sha256:a027a470aa2b9b41cc2539847a97b8a14794ebd0a4c7c5d64e390df6bde56c73 | jq -r '.layers[] | .digest' | xargs -n1 -P10 ./dist fetch docker.io/library/redis > /dev/null
```
This is just the beginning. We should be able to centralize
configuration around fetch to implement a number of distribution
methodologies that have been challenging or impossible up to this point.
The `locator`, mentioned earlier, is a schemaless URL that provides a
host and path that can be used to resolve the remote. By dispatching on
this common identifier, we should be able to support almost any protocol
and discovery mechanism imaginable.
When this is more solidified, we can roll these up into higher-level
operations that can be orchestrated through the `dist` tool or via GRPC.
What a time to be alive!
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Initial vendor list validated with empty $GOPATH
and only master checked out; followed by `make`
and verified that all binaries build properly.
Updates require github.com/LK4D4/vndr tool.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
