This is the most complex part to cache, as the cached component can be
only used if:
* There were no changes in the agent
* There were no changes in the libs (used by the agent)
* There were no changes in the rootfs build scripts
* There is no change in the version of the following components:
* attestation-agent (part of the rootfs)
* gperf (used to build libseccomp)
* libseccomp (used to build the agent)
* pause image (part of the rootfs)
* skopeo (part of the rootfs)
* umoci (part of the rootfs)
* rust (used to build the kata-containers and attestation agents)
We're relying on the last commit merged on places related to the rootfs
generation and using that as the rootfs version and that should be good
enough for what we need.
Apart from everything already mentioned, we've also added the ability to
cache the `root_hash_vanilla.txt` and `root_hash_tdx.txt` files, as
those are needed for when building the shim-v2, in order to have
measured boot working there.
It's important to note that we've added the ability to cache *both*
files, and I've taken that path as the shim-v2 cache work (which will
come soon) relies on both files.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This will help us, in the future, to debug any possible issue related to
the measured rootfs arguments passed to the shim during the build time.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
By doing this we can ensure that when building different rootfs-images
we won't end up overring the `root_hash.txt` file.
Plus, this will help us later in this series to pass the correct
argument to be used with the respective image.
Nothing's been done for SEV as it uses a initrd instead of an image.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Adding the `root_hash.txt` to the final tarball doesn't bring any
benefit to the project, as the file dependency is for building the
shim-v2 and passing the correct measurement for the kernel command line.
It's important to mention that when building shim-v2, it doesn't look
for the file in `/opt/confidential-containers/share/kata-containers`,
bur rather in the `${repo_root_dir}/tools/osbuilder/`, as shown here:
ac3683e26e/tools/packaging/kata-deploy/local-build/kata-deploy-binaries.sh (L228-L232)
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
It turns out that there's more work needed to be done on the Cloud
Hypervisor side so we can fully support EAA_KBC with it.
For now, let's remove the configuration as the tests are not currently
passing when using it, and stick to the `offline_fs_kbc` and its
specific image for the Cloud Hypervisor + TDX case.
Fixes: #5862
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The `qemu-tdx` configuration is tied to using `offline_fs_kbc` as the
aa_kbc, which is something we're moving away from.
With this in mind, let's rename the `qemu-tdx-eaa-kbc` to `qemu-tdx` and
decrease the amount of the way too many configurations that we ship.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As already done for install_cc_kernel(), let's ensure we export
KATA_BUILD_CC=yes as part of the install_cc_tee_kernel.
This is used to generate the hash of the devices in the initramfs.
Fixes: #5845
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's move the info about building initramfs to *after* trying to
install the cached components.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This PR allow us to use the virtiofsd cache tarball instead of
building it from source.
Fixes#5356
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
It seems that the Kata Containers jenkins may be very slow to reach from
behind the firewall, causing TDX machine to fail downloading some of the
cached artefacts.
With this in mind, let's switch to using wget for this specific case.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's avoid getting into a dir and risking not being able to leave that
dir in case something fails.
Instead, let's just stay in the current dir and move the final tarball
to the exoected directory in case all the checks go as expected.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
With the cached version we're concatenating the td-shim version with the
toolchain version used to build the project.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a documentation about the environment variables that can be
used with the `-k` and `-q` options.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The `qemu_script_dir` is a leftover from before the rework on how we
cache the components.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As we're already doing for some components, let's also add support for
caching firmwares. TD-Shim and TDVF are the ones supported for now.
Fixes: #5360, #5361
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We should use {} instead of () when passing the component version to the
install_cached_component() function.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
asserts -> assets
stastic -> static
Those were not caught during the first merge of the series as we didn't
have CI jobs testing for the TEE artefacts.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're currently building Cloud Hypervusor with thE TDX feature
regardless of using with TDX or not.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The name of the asset was wrong, "cloud-hypervisor" instead of
"hypervisor.cloud_hypervsior", generating an empty "latest" file.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The final cloud hypervisor tarball name is either
kata-static-cc-cloud-hypervisor.tar.xz or
kata-static-cc-tdx-cloud-hypervisor.tar.xz, meaning it uses
"cloud-hypervisor" instead of "clh" in the name.
Fixes: #5816
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's check for the cached version of the components as part of the
kata-deploy-binaries.sh as here we already have the needed info for
checking whether a component is cached or not, and to use it without
depending on changes made on each one of the builder scripts.
Fixes: #5816
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of caching files generated during the component build, let's
cache the final tarball generated for each component.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's do this as the component name will be re-used later on, when we
start checking whether a cached component needs to be rebuilt or not.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is used in several parts of the code, and can have a single
declaration as part of the `lib.sh` file, which is already imported by
all the places where it's used.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're going to use this function from different places, so we better
move it to lib.sh and avoid rewriting it.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
If you're directly using the output of this function, the info message
will show up as part of the string, and that's not what we want.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Now that we're caching the kernel, we're relying on the kernel version
being exported. This is already done for the CC kernel, but not for the
TEE specific ones.
Fixes: #5770
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
CONFIG_X86_SGX is introduced after kernel 5.11, and that config is a
default x86_64 config for Kata build-kernel.sh script.
But if we use -v to specify any kernel version below 5.11 will cause an
inevitable error because CONFIG_X86_SGX is not supported in older
kernels and that may cause problem for the situation if we need kernel
version below 5.11.
So I propose to put CONFIG_X86_SGX into whitelist.conf to avoid break
building guest kernel below 5.11.
fixes: #5741
Signed-off-by: Chao Wu <chaowu@linux.alibaba.com>
