TDVF is the firmware used by QEMU to start TDX capable VMs. Let's start
tracking it as it'll become part of the Confidential Containers sooner
or later.
TDVF lives in the public https://github.com/tianocore/edk2-staging repo
and we're using as its version tags that are consumed internally at
Intel.
Fixes: #4624
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of having as a result the directory where OVMF artefacts where
installed, let's follow what we do with the other components and have a
tarball as a result of the OVMF build.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of cloning the repo, and then switching to a specific branch,
let's take advantage of `--branch` and directly clone the specific
branch / tag.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As TDVF comes from a different repo, the edk2-staging one, we cannot
simply hardcode the name. Instead, let's get the name of the directory
from name of the git repo.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
TD-shim is a simplified TDX virtual firmware, used by Cloud Hypervisor,
in order to create a TDX capable VM.
TD-shim is heavily under development, and is hosted as part of the
Confidential Containers project:
https://github.com/confidential-containers/td-shim
The version chosen for this commit, is a version that's being tested
inside Intel, but we, most likely, will need to change it before we have
it officially packaged as part of an official release.
Fixes: #4779
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
io_uring is a Linux API for asynchronous I/O introduced in qemu 5.0.
It is designed to better performance than older aio API.
We could leverage this in order to get better storage performance.
We should be adding liburing-dev to qemu build to leverage this feature.
However liburing-dev package is not available in ubuntu 20.04,
it is avaiable in 22.04.
Upgrading the ubuntu version in the dockerfile to 22.04 is causing
issues in the static qemu build related to libpmem.
So instead we are building liburing from source until those build issues
are solved.
Fixes: #4645
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
We're adding a new target for building a TDX capable Cloud Hypervisor
for CC.
As the current version of Cloud Hypervisor is already built with TDX
support, we just rely on calling the same `install_cc_clh()` function,
as done for the non-tee `cc` target.
Fixes: #4659
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building a TDX capable QEMU for CC.
This commit, differently than b307531c29,
introduces support for building the artefacts that are TEE specific.
Fixes: #4623
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Currently $BUILD_DIR will be used to create a directory as:
/opt/kata/share/kata-qemu${BUILD_DIR}
It means that when passing a BUILD_DIR, like "foo", a name would be
built like /opt/kata/share/kata-qemufoo
We should, instead, be building it as /opt/kata/share/kata-qemu-foo.
Fixes: #4638
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Currently $BUILD_DIR will be used to create a directory as:
/opt/kata/share/kata-qemu${BUILD_DIR}
It means that when passing a BUILD_DIR, like "foo", a name would be
built like /opt/kata/share/kata-qemufoo
We should, instead, be building it as /opt/kata/share/kata-qemu-foo.
Fixes: #4638
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
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>
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>
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>
Instead of passing a `KATA_CONF_FILE` environament variable, let's rely
on the configured (in the container engine) config path, as both
containerd and CRI-O support it, and we're using this for both of them.
Fixes: #4608
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As we're already doing for containerd, let's also pass the configuration
path to CRI-O, as all the supported CRI-O versions do support this
configuration option.
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>
This is not an issue when the build is run as non-privilged user.
Marking these as safe in case where the build may be run as root
or some other user.
Signed-off-by: Archana Shinde <archana.m.shinde@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>
While running make as non-privileged user, the make errors out with
the following message:
"INFO: Build cloud-hypervisor enabling the following features: tdx
Got permission denied while trying to connect to the Docker daemon
socket at unix:///var/run/docker.sock: Post
"http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/create?fromImage=cloudhypervisor%2Fdev&tag=20220524-0":
dial unix /var/run/docker.sock: connect: permission denied"
Even though the user may be part of docker group, the clh build from
source does a docker in docker build. It is necessary for the user of
the nested container to be part of docker build for the build to
succeed.
Fixes#4594
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
Replaces calls of nproc with nproc with
nproc ${CI:+--ignore 1}
to run nproc with one less processing unit than the maximum to prevent
DOS-ing the local machine.
If process is being run in a container (determined via whether $CI is
null), all processing units avaliable will be used.
Fixes#3967
Signed-off-by: Derek Lee <derlee@redhat.com>
As 2.5.0-rc0 has been released, let's switch the kata-deploy / kata-cleanup
tags back to "latest", and re-add the kata-deploy-stable and the
kata-cleanup-stable files.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
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>
