AMD SEV pre-attestation is handled by the runtime before the guest is
launched. Guest VM is started paused and the runtime communicates with a
remote keybroker service (e.g., simple-kbs) to validate the attestation
measurement and to receive launch secret. Upon validation, the launch
secret is injected into guest memory and the VM is started.
Fixes: #4280
Signed-off-by: Jim Cadden <jcadden@ibm.com>
Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
This PR updates the libseccomp version at the versions.yaml that is
being used in the kata CI.
Fixes#4858
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
"We need a newer nightly 1.62 rust to deal with the change
rust-lang/libc@576f778 on crate libc which breaks the compilation."
This comes from the a pull-request raised on TD-shim repo,
https://github.com/confidential-containers/td-shim/pull/354, which fixes
the issues with the commit being used with Kata Containers.
Let's bump to a newer commit of TD-shim and to a newer version of the
nightly toolchain as part of our versions file.
Fixes: #4840
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
"An empty [workspace] can be used with a package to conveniently create a
workspace with the package and all of its path dependencies", according
to the https://doc.rust-lang.org/cargo/reference/workspaces.html
This is also matches with the suggestion provided by the Cargo itself,
due to the errors faced with the Cloud Hypervisor CI:
```
10:46:23 this may be fixable by adding `go/src/github.com/kata-containers/kata-containers/src/tools/agent-ctl` to the `workspace.members` array of the manifest located at: /tmp/jenkins/workspace/kata-containers-2-clh-PR/Cargo.toml
10:46:23 Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
```
Fixes: #4843
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The file was added as part of the commit that tested this changes in the
CCv0 branch, but forgotten when re-writing it to the `main` branch.
Fixes: #4841
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
If the API server is not ready, the mount call will fail, so before
mounting share fs, we should wait the nydusd is started and
the API server is ready.
Fixes: #4710
Signed-off-by: liubin <liubin0329@gmail.com>
Signed-off-by: Bin Liu <bin@hyper.sh>
Let's add the QEMU TDX targets to be generated together with the cc
targets, when calling `make cc-tarball`.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As the previous commit added a new runtime class to be used with TDX,
let's make sure this gets shipped and configured as part of the
kata-deploy-cc script, which is used by the Confidential Containers
Operator.
This commit also cleans up all the extra artefacts that will be
installed in order to run the QEMU TDX workloads.
Fixes: #4832
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a new configuration file for using a QEMU (and all the needed
artefacts) that are TDX capable.
This PR extends the Makefile in order to provide variables to be set
during the build time that are needed for the proper configuration of
the VMM, such as:
* Specific kernel parameters to be used with TDX
* Specific kernel features to be used when using TDX
* Artefacts path for the artefacts built to be used with TDX
* QEMU
* Kernel
* TDVF
The reason we don't hack into the current QEMU configuration file is
because we want to ship both configurations, with for the non-TEE use
case and one for the TDX use case.
Fixes: #4830
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of passing a bunch of arguments to qmp functions for
adding block devices, use govmm BlockDevice structure to reduce these.
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
Get rid of redundant return values from function.
args and blockdevArgs used to return different values to maintain
compatilibity between qemu versions. These are exactly the same now.
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
This configuration will allow users to choose between different
I/O backends for qemu, with the default being io_uring.
This will allow users to fallback to a different I/O mechanism while
running on kernels olders than 5.1.
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
Remove line about annotations support in CRI-O and containerd since it
has been supported for a couple years.
Fixes#4819
Signed-off-by: Chelsea Mafrica <chelsea.e.mafrica@intel.com>
To keep runtime-rs up to date, we will merge main into runtime-rs every
week.
Fixes:kata-containers#4822
Signed-off-by: Zhongtao Hu <zhongtaohu.tim@linux.alibaba.com>
Update documentation with details regarding
intel-device-plugins-for-kubernetes setup and dependencies.
Fixes#4819
Signed-off-by: Chelsea Mafrica <chelsea.e.mafrica@intel.com>
github.com/kata-containers/tests#4986.To avoid returning an error when
running the ci, we just skip the test if the arch is s390x
Fixes: #4816
Signed-off-by: Zhongtao Hu <zhongtaohu.tim@linux.alibaba.com>
github.com/kata-containers/tests#4986.To avoid returning an error when running the ci, we just skip the build
process if the arch is s390x
Fixes: #4816
Signed-off-by: Zhongtao Hu <zhongtaohu.tim@linux.alibaba.com>
io_uring was introduced as a new kernel IO interface in kernel 5.1.
It is designed for higher performance than the older Linux AIO API.
This feature was added in qemu 5.0.
Fixes#4645
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
We're adding a new target for building TD-shim, a firmware used with
Cloud Hypervisor to start TDX capable VMs for CC.
Fixes: #4780
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're adding a new target for building a TDVF, a firmware used with QEMU
to start TDX capable VMs for CC.
Fixes: #4625
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's create the td-shim tarball in the directory where the script was
called from, instead of doing it in the $DESTDIR.
This aligns with the logic being used for creating / extracting the
tarball content, which is already in use by the kata-deploy local build
scripts.
Fixes: #4809
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's create the OVMF tarball in the directory where the script was
called from, instead of doing it in the $DESTDIR.
This aligns with the logic being used for creating / extracting the
tarball content, which is already in use by the kata-deploy local build
scripts.
Fixes: #4808
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's create the td-shim tarball in the directory where the script was
called from, instead of doing it in the $DESTDIR.
This aligns with the logic being used for creating / extracting the
tarball content, which is already in use by the kata-deploy local build
scripts.
Fixes: #4809
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's create the OVMF tarball in the directory where the script was
called from, instead of doing it in the $DESTDIR.
This aligns with the logic being used for creating / extracting the
tarball content, which is already in use by the kata-deploy local build
scripts.
Fixes: #4808
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
