Adds oci under the src/libs workplace.
oci shares a Cargo.lock file with the rest of src/libs but was not
listed as a member of the workspace.
There is no clear reason why it is not included in the workspace, so
adding it so cargo-deny stop complaining
Signed-off-by: Derek Lee <derlee@redhat.com>
One of the checks done by cargo-deny is ensuring all crates have a valid
license. As the rust programs import each other, cargo.toml files
without licenses trigger the check. While I could disable this check
this would be bad practice.
This adds an Apache-2.0 license in the Cargo.toml files.
Some of these files already had a header comment saying it is an Apache
license. As the entire project itself is under an Apache-2.0 license, I
assumed all individual components would also be covered under that
license.
Signed-off-by: Derek Lee <derlee@redhat.com>
Adds cargo-deny to scan for vulnerabilities and license issues regarding
rust crates.
GitHub Actions does not have an obvious way to loop over each of the
Cargo.toml files. To avoid hardcoding it, I worked around the problem
using a composite action that first generates the cargo-deny action by
finding all Cargo.toml files before calling this new generated action in
the master workflow.
Uses recommended deny.toml from cargo-deny repo with the following
modifications:
ignore = ["RUSTSEC-2020-0071"]
because chrono is dependent on the version of time with the
vulnerability and there is no simple workaround
multiple-versions = "allow"
Because of the above error and other packages, there are instances
where some crates require different versions of a crate.
unknown-git = "allow"
I don't see a particular issue with allowing crates from other repos.
An alternative would be the manually set each repo we want in an
allow-git list, but I see this as more of a nuisance that its worth.
We could leave this as a warning (default), but to avoid clutter I'm
going to allow it.
If deny.toml needs to be edited in the future, here's the guide:
https://embarkstudios.github.io/cargo-deny/index.htmlFixes#3359
Signed-off-by: Derek Lee <derlee@redhat.com>
This PR updates the cni plugins version that is being used in the kata CI.
Fixes#5039
Depends-on: github.com/kata-containers/tests#5088
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
This removes two options that are not needed (any longer). These
are not set for any kernel so they do not need to be ignored either.
Fixes#5035
Signed-off-by: Joana Pecholt <joana.pecholt@aisec.fraunhofer.de>
The agent configuration file, which is part of the docs, is used by the
confidential containers CIs and, right now, cannot be run behind a
firewall, which is exactly how the TDX CIs are reunning, as https_proxy
is not set there.
Fixes: #5020
Depends-on: github.com/kata-containers/tests#5080
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Guest log is showing a hang on systemd getty start.
Adding symlink for /dev/ttyS0 resolves issue.
Fixes: #4932
Signed-Off-By: Ryan Savino <ryan.savino@amd.com>
Somewhere is lack of log info, add more details about
the storage and log when error will help understand
what happened.
Fixes: #4962
Signed-off-by: Bin Liu <bin@hyper.sh>
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 CLH TDX workloads.
Fixes: #4833
Depends-on: github.com/kata-containers/tests#5070
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a new configuration file for using a cloud hypervisor (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
* Kernel
* TD-Shim
The reason we don't hack into the current Cloud Hypervisor configuration
file is because we want to ship both configurations, with for the
non-TEE use case and one for the TDX use case.
It's important to note that the Cloud Hypervisor used upstream is
already built with TDX support.
Fixes: #4831
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
TDX kernel is based on a kernel version which doesn't have the
CONFIG_SPECULATION_MITIGATIONS option.
Having this in the allow list for missing configs avoids a breakage in
the TDX CI.
Fixes: #4998
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
TDX kernel is based on a kernel version which doesn't have the
CONFIG_SPECULATION_MITIGATIONS option.
Having this in the allow list for missing configs avoids a breakage in
the TDX CI.
Fixes: #4998
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
With the current TDX kernel used with Kata Containers, `tdx_guest` is
not needed, as TDX_GUEST is now a kernel configuration.
With this in mind, let's just drop the kernel parameter.
Fixes: #4981
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As right now the TDX guest kernel doesn't support "serial" console,
let's switch to using HVC in this case.
Fixes: #4980
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The runtime will crash when trying to resize memory when memory hotplug
is not allowed.
This happens because we cannot simply set the hotplug amount to zero,
leading is to not set memory hotplug at all, and later then trying to
access the value of a nil pointer.
Fixes: #4979
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
While doing tests using `ctr`, I've noticed that I've been hitting those
timeouts more frequently than expected.
Till we find the root cause of the issue (which is *not* in the Kata
Containers), let's increase the timeouts when dealing with a
Confidential Guest.
Fixes: #4978
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
When booting the TDX kernel with `tdx_disable_filter`, as it's been done
for QEMU, VirtioFS can work without any issues.
Whether this will be part of the upstream kernel or not is a different
story, but it easily could make it there as Cloud Hypervisor relies on
the VIRTIO_F_IOMMU_PLATFORM feature, which forces the guest to use the
DMA API, making these devices compatible with TDX.
See Sebastien Boeuf's explanation of this in the
3c973fa7ce208e7113f69424b7574b83f584885d commit:
"""
By using DMA API, the guest triggers the TDX codepath to share some of
the guest memory, in particular the virtqueues and associated buffers so
that the VMM and vhost-user backends/processes can access this memory.
"""
Fixes: #4977
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Users can specify the kernel module to be loaded through the agent
configuration in kata configuration file or in pod anotation file.
And information of those modules will be sent to kata agent when
sandbox is created.
Fixes: #4894
Signed-off-by: Yushuo <y-shuo@linux.alibaba.com>
The `force_tdx_guest` kernel parameter was only needed in the early
development stages of the TDX kernel driver. We can safely drop it with
the kernel version we've been currently using.
Fixes: #4985
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
With the current TDX kernel used with Kata Containers, `tdx_guest` is
not needed, as TDX_GUEST is now a kernel configuration.
With this in mind, let's just drop the kernel parameter.
Fixes: #4981
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As right now the TDX guest kernel doesn't support "serial" console,
let's switch to using HVC in this case.
Fixes: #4980
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The runtime will crash when trying to resize memory when memory hotplug
is not allowed.
This happens because we cannot simply set the hotplug amount to zero,
leading is to not set memory hotplug at all, and later then trying to
access the value of a nil pointer.
Fixes: #4979
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
While doing tests using `ctr`, I've noticed that I've been hitting those
timeouts more frequently than expected.
Till we find the root cause of the issue (which is *not* in the Kata
Containers), let's increase the timeouts when dealing with a
Confidential Guest.
Fixes: #4978
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Add cli message for init command to tell the user
not to run this command directly.
Fixes: #4367
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
When booting the TDX kernel with `tdx_disable_filter`, as it's been done
for QEMU, VirtioFS can work without any issues.
Whether this will be part of the upstream kernel or not is a different
story, but it easily could make it there as Cloud Hypervisor relies on
the VIRTIO_F_IOMMU_PLATFORM feature, which forces the guest to use the
DMA API, making these devices compatible with TDX.
See Sebastien Boeuf's explanation of this in the
3c973fa7ce208e7113f69424b7574b83f584885d commit:
"""
By using DMA API, the guest triggers the TDX codepath to share some of
the guest memory, in particular the virtqueues and associated buffers so
that the VMM and vhost-user backends/processes can access this memory.
"""
Fixes: #4977
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
