Instead of always naming the binary as "-experimental", let's take
advantage of the $BUILD_SUFFIX that's already passed and correctly name
the binary according to it.
Fixes: #4638
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building a TDX capable kernel for CC.
This commit, differently than c4cc16efcd,
introduces support for building the artefacts that are TEE specific.
Fixes: #4622
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Passing the URL to be used to download the kernel tarball is useful in
various scenarios, mainly when doing a downstream build, thus let's add
this new option.
This new option also works around a known issue of the Dockerfile used
to build the kernel not having `yq` installed.
Fixes: #4629
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
There's no need to have the entire function for building SEV / TDX
duplicated.
Let's remove those functions and create a `get_tee_kernel()` which takes
the TEE as the argument.
Fixes: #4627
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Although I don't like the duplication introduced here, it's (at least
for now) way cleaner to have a specific daemonset for the Confidential
Containers effort.
As soon as we have all the bits and pieces upstreamed (kernel, QEMU, and
specific dependencies for each one of the TEEs), we'll be easily able to
get rid of this one. However, for now, focusing on this different set
of files will make our lives easier.
This new daemonset includes the configurations needed for containerd in
order to use the `cc` specific `cri_handler`, which is not and will not
be upstream on the containerd side.
Note, CRI-O is **not** supported for now.
Fixes: #4620
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of hacking the original `kata-deploy.sh` script, let's add a
totally new folder where we'll be adding content that's CC related.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
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>
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>
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>
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>
This PR removes an unused kata configure docker script which was used
in packaging for kata 1.x but not longer being used in kata 2.x
Fixes#4546
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
The apply_patches.sh script applies all patches in the patches
directory, as well as subdirectories. This means if there is a sub-dir
called "experimental" under a major kernel version directory,
experimental patches would be applied to the default kernel supported by
Kata.
We did not come accross this issue earlier as typically the experimental
kernel version was different from the default kernel.
With both the default kernel and the arm-experimental kernel having the
same major kernel version (5.15.x) at this time, trying to update the
kernel patch version revealed that arm-experimental patches were being
applied to the default kernel.
Restricting the patches to be applied to the top level directory will
solve the issue. The apply_patches script should ignore any
sub-directories meant for experimental patches.
Fixes#4520
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
Otherwise `./build-kernel.sh -x tdx setup` will fail with the following
error:
```
$ ./build-kernel.sh -x tdx setup
INFO: Config version: 92
INFO: Kernel version: tdx-guest-v5.15-4
INFO: kernel path does not exist, will download kernel
INFO: Apply patches from
/home/ffidenci/go/src/github.com/kata-containers/kata-containers/tools/packaging/kernel/patches/tdx-guest-v5.15-4.x
INFO: Found 0 patches
INFO: Enabling config for 'tdx' confidential guest protection
INFO: Constructing config from fragments:
/home/ffidenci/go/src/github.com/kata-containers/kata-containers/tools/packaging/kernel/configs/fragments/x86_64/.config
WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
Depends on [n]: EFI [=n] && EFI_STUB [=n]
Selected by [y]:
- INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] &&
CPU_SUP_INTEL [=y] && PARAVIRT [=y] && SECURITY [=y] &&
X86_X2APIC[=y]
INFO: Some CONFIG elements failed to make the final .config:
INFO: Value requested for CONFIG_EFI_STUB not in final .config
INFO: Generated config file can be found in
/home/ffidenci/go/src/github.com/kata-containers/kata-containers/tools/packaging/kernel/configs/fragments/x86_64/.config
ERROR: Failed to construct requested .config file
ERROR: failed to find default config
```
Fixes: #4510
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This PR removes unused the publish kata image script which
was used on kata 1.x when we had OBS packages which are not
longer used on kata 2.x
Fixes#4496
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
So far this has been done for x86_64. Now that the support for building
and testing has been added for all arches, let's do the second part of
the switch.
We're still not done yet for powerpc, as some a virtifosd crash on the
rust version has been found by the maintainer.
Fixes: #4258, #4260
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Add kernel fork for sev to kernel builder with efi_secret. Additionally, install efi_secret module for sev.
Fixes: #4179
Signed-off-by: Alex Carter <alex.carter@ibm.com>
Since we are introducing an agent API for interacting with guest
iptables, let's ensure that our example rootfs' have iptables-save/restore
installed.
Fixes: #4356
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
Based on @fidencio's opoinon,
On Arm: static build virtiofsd using musl lib;
on ppc64 & s390: static build virtiofsd using gnu lib;
Fixes: #4258
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
This PR removes the clear containers reference as this is not longer
being used and is deprecated at the rootfs builder README.
Fixes#4278
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
Destructive mode is required to build the Kata Containers snap. See:
```
.github/workflows/snap-release.yaml
.github/workflows/snap.yaml
```
Hence, update the last file that we forgot to update with
`--destructive-mode`.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Move the snap README to a subdirectory to resolve the warning given by
`snapcraft` (folded and reformatted slightly for clarity):
```
The 'snap' directory is meant specifically for snapcraft,
but it contains the following non-snapcraft-related paths,
which is unsupported and will cause unexpected behavior:
- README.md
If you must store these files within the 'snap' directory,
move them to 'snap/local', which is ignored by snapcraft.
```
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Based on @fidencio's opoinon,
On Arm: static build virtiofsd using musl lib;
on ppc64 & s390: static build virtiofsd using gnu lib;
Fixes: #4258
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
