kata-deploy files must be adapted to a new release. The cases where it
happens are when the release goes from -> to:
* main -> stable:
* kata-deploy-stable / kata-cleanup-stable: are removed
* stable -> stable:
* kata-deploy / kata-cleanup: bump the release to the new one.
There are no changes when doing an alpha release, as the files on the
"main" branch always point to the "latest" and "stable" tags.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
add create_vcpu() function in vcpu test unit for aarch64
Fixes: #4445
Signed-off-by: xuejun-xj <jiyunxue@linux.alibaba.com>
Signed-off-by: jingshan <jingshan@linux.alibaba.com>
Replace `libc::setgroups()`, `libc::fchown()`, and `libc::sethostname()`
functions with nix crate ones for safety and maintainability.
Fixes: #4579
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
Run the OCI `poststart` hooks must be called after the
user-specified process is executed but before the `start`
operation returns in accordance with OCI runtime spec.
Fixes: #4575
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
Some clients like nerdctl may pass mount type of none for volumes/bind mounts,
this will lead to container start fails.
Referring to runc, it overwrites the mount type to bind and ignores the input value.
Fixes: #4548
Signed-off-by: liubin <liubin0329@gmail.com>
While doing a docker build for shim-v2, we see this:
```
fatal: unsafe repository
('/home/${user}/go/src/github.com/kata-containers/kata-containers' is
owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory
/home/${user}/go/src/github.com/kata-containers/kata-containers
```
This is because the docker container build is run as root while the
runtime repo is checked out as normal user.
Unlike this error causing the rootfs build to error out, the error here
does not really cause `make shim-v2-tarball` to fail.
However its good to get rid of this error message showing during the
make process.
Fixes: #4572
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
We've added a bunch of new options related to Confidential Containers
builds as part of the kata-deploy-binaries.sh. Let's make sure those
are displayed to the users of the script when it's called with --help.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Similar to what we have with the `all` option, let's also add a `cc`
one, allowing others to easily call the script and build all the `cc`
related components.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Quite similar to the `kata-tarball` target, let's add a `cc-tarball`
target so we can build all the CC related tarballs in a single command,
with all the tarballs being merged together in the end.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Quite similar to the `all-parallel` target, let's add a `cc-parallel`
target so we can build all the CC related tarballs in parallel.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Quite similar to the `all` target, let's add a `cc` target so we can
build all the CC related tarballs.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building virtiofsd for CC, but it's
important to note that the only difference between this one and the
"vanilla" build is the installation path.
Moreover, virtiofsd will **NOT** be used by the CC effort, but as the
very first release target doesn't include TEE support, let's not force
those who want to give it a try to setup devicemapper.
Fixes: #4569
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building QEMU for CC, but it's important
to note that the only difference between this one and the "vanilla"
build is the installation path.
The reason we're taking this approach is because the first release
target for CC doesn't include TEE support.
We had to also include a new builder for QEMU, a specific one for CC, as
for now that's the easiest way to override the prefix in a way that
we'll be easily able to expand the script to support TEE capable builds
in the very near future.
Fixes: #4568
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building the Kernel for CC, but it's
important to note that the only difference between this one and the
"vanilla" build is the installation path.
The reason we're taking this approach is because the first release
target for CC doesn't include TEE support.
Fixes: #4567
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building Cloud Hypervisor for CC, but it's
important to note that the only difference between this one and the
"vanilla" build is the installation path.
The reasons we're taking this approach are:
* Cloud Hypervisor, for the `main` and `stable` branches, is already
built with TDX support.
* The first target for the CC release doesn't include TEE support.
Fixes: #4566
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a new build target for our local-build scripts, cc-shim-v2,
and use it to build Kata Containers properly configured for the CC
use-case.
Fixes: #4564
Depends-on: github.com/kata-containers/tests#4895
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a new "REMOVE_VMM_CONFIGS" environment variable that can be
passsed to the script responsible for building Kata Containers.
Right now this is not useful for the `main` or `stable` branch, but for
the CC release we only have been working and testing with QEMU and Cloud
Hypervisor.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
For the CC build we need to enable such a flag, and the cleaner way to
do so is exposing it in the Makefile and, later on, making sure its
correct value to the build script.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
While this has never been needed for the `main` and `stable` releases,
for the coming CC release we need to pass a few extra options when
building the shim.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Set `safe.directory` against `kata-containers/tests` repository
before checkout because the user in the docker container is root,
but the `tests` repository on the host machine is usually owned
by the normal user.
This works when we already have the `tests` repository which is
not owned by root on the host machine and try to create a rootfs
using Docker (`USE_DOCKER=true`).
Fixes: #4561
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
For runC, send the signal to the init process directly.
For kata, we try to send `SIGKILL` instead of `SIGTERM` when the process
has not installed the handler for `SIGTERM`.
The `is_signal_handled` function determine which signal the container
process has been handled. But currently `is_signal_handled` is only
catching (SigCgt). While the container process is ignoring (SigIgn) or
blocking (SigBlk) also should not be converted from the `SIGTERM` to
`SIGKILL`. For example, when using terminationGracePeriodSeconds the k8s
will send SIGTERM first and then send `SIGKILL`, in this case, the
container ignores the `SIGTERM`, so we should send the `SIGTERM` not the
`SIGKILL` to the container.
Fixes: #4478
Signed-off-by: quanweiZhou <quanweiZhou@linux.alibaba.com>
Recently added check-commit-message to the tests repository. Minor
changes were also made to action. For consistency's sake, copied changes
over to here as well.
tests - https://github.com/kata-containers/tests/pull/4878
Minor Changes:
1. Body length check is now 75 and consistent with guidelines
2. Lines without spaces are not counted in body length check
Fixes#4559
Signed-off-by: Derek Lee <derlee@redhat.com>
Let's add a new build target for our local-build scripts,
cc-rootfs-image-tarball, and use it to build an image that has skopeo
and umoci embedded in, and that using the offline_fs_kbc as the
attenstation agent KBC.
Fixes: #4557
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
SKOPEO, UMOCI, and AA_KBC have been unset so far as we have not been
generating rootfs images that would be used for CC as part of our
workflow.
Now, as we're targetting the first release of the operator with the CCv0
branch, let's stop unsetting those and start taking advantage of our
tools to help us building a CC capable image.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
