Add qemu-coco-dev-runtime-rs with experimental-force-guest-pull
to the CoCo non-TEE test matrices. This exercises the force
guest pull code path on runtime-rs, which uses the
`runtime.experimental = ["force_guest_pull"]` configuration.
The new entries are added to both the standard nontee matrix
(vanilla k8s) and the extensive matrix (k0s, k3s, rke2, microk8s).
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The Go runtime uses `runtime.experimental_force_guest_pull = true`
(a boolean TOML field) while runtime-rs uses the experimental
features array: `runtime.experimental = ["force_guest_pull"]`.
Update `configure_experimental_force_guest_pull()` to detect
runtime-rs shims and append "force_guest_pull" to the
`runtime.experimental` array instead of setting the Go-style
boolean. This enables kata-deploy to correctly configure the
force guest pull feature for runtime-rs based deployments.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Network devices for VM-based containers are allowed to be placed in the
host netns to eliminate as many hops as possible, which is what we
aim for to achieve near-native networking performance.
This commit introduces the `dan_conf` field to the configuration file.
This allows the runtime to specify the configuration path for
Direct Attached Network (DAN) devices, enabling interfaces to remain
in the host network namespace while being utilized by the VM-based(qemu)
containers.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
In CoCo scenarios, there's no memory-agent involved, to reduce
users' misleadings, it's better to directly remove the section.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
The experimental configuration allows enabling features not yet
stable for production. These features may break compatibility and
are prepared for major version bumps.
Add documentation with force_guest_pull example across all
runtime-rs configuration files. This feature enables guest-side
image pulling in CoCo (Confidential Computing) scenarios.
Updated configurations:
- configuration-dragonball.toml.in
- configuration-qemu-runtime-rs.toml.in
- configuration-remote.toml.in
- configuration-rs-fc.toml.in
The following already had this documentation:
- configuration-cloud-hypervisor.toml.in
- configuration-qemu-coco-dev-runtime-rs.toml.in
- configuration-qemu-se-runtime-rs.toml.in
- configuration-qemu-snp-runtime-rs.toml.in
- configuration-qemu-tdx-runtime-rs.toml.in
Example usage:
experimental = ["force_guest_pull"]
Fixes inconsistent documentation across configuration files
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Without this commit any attempt to exec a command in a container will fail
if SELinux is disabled in the guest but an SELinux label is given for
the new process. That will happen pretty much any time SELinux is enabled
on the host (and the container is not privileged).
Signed-off-by: Pavel Mores <pmores@redhat.com>
We'll need to get the `disable_guest_linux` value in the exec handler, too.
This will allow us to avoid duplicating the get.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Simple bump to fix CVE GHSA-82j2-j2ch-gfr8:
Denial of service via panic on malformed CRL BIT STRING
Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Device plugins may set PCIDEVICE_* environment variables with
non-PCI identifiers (e.g. "mlx5_core.sf.10" for mlx5 Scalable
Functions). The update_env_pci() function assumed all values were
PCI BDF addresses and failed to parse them, causing container
creation to fail with:
"PCI address mlx5_core.sf.10 should have the format DDDD:BB:SS.F"
Skip PCIDEVICE_* entries whose values don't parse as PCI addresses,
leaving them untouched for the workload. The corresponding _INFO
variable is also left as-is since no mapping is collected.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Same fix as the Go runtime: interfaces whose drivers do not register
a specific netlink kind (e.g. mlx5 Scalable Functions) are reported
with the generic type "device", which is not handled by the endpoint
creation match, causing sandbox creation to fail with:
"unsupported link type: device"
Add "device" as an alternative pattern alongside "veth" so these
interfaces are connected through a TAP + TC-filter bridge.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Interfaces whose drivers do not register a specific netlink kind
(e.g. mlx5 Scalable Functions) are reported with the generic type
"device". The endpoint creation code did not handle this type,
causing sandbox creation to fail with:
"Unsupported network interface: device"
This is particularly visible on arm64 with Mellanox ConnectX NICs
using Scalable Functions, where the ethtool BusInfo returns a
non-PCI identifier (e.g. "mlx5_core.sf.4") so isPhysicalIface()
cannot classify the interface as physical either.
Handle "device" type interfaces the same way as veth endpoints,
connecting them through a TAP + TC-filter bridge.
Additionally, relax getLinkForEndpoint() for VethEndpoint so it
accepts the concrete link type returned by the kernel instead of
asserting *netlink.Veth. A "device" type interface wrapped in a
VethEndpoint returns *netlink.Device from LinkByName(), which
would fail the strict type assertion. All callers only need
link.Attrs(), so accepting any link type is safe.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
At first we thought this only happened with AKS, but it seems this is a
change in k8s 1.36.0 as the tests now started failing outside of AKS as
well.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
All the CIs are failing on the tests and in order to avoid blocking
upstream while allowing enough time for the developers to properly fix
it, let's just not execute the test.
This commit should be reverted once a fix is proposed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Dragonball is only supported on x86_64 and aarch64, so using it as the
default hypervisor means architectures like s390x, powerpc64le, and
riscv64gc have no working default. Switch to QEMU, which is available
across all supported architectures.
Dragonball is still compiled as a feature on x86_64 and aarch64 via
USE_BUILTIN_DB, and users can still override the default with
HYPERVISOR=dragonball.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The arm64 k8s tests are expensive and consume self-hosted runner
resources. Restrict both run-k8s-tests-on-arm64 and
run-kata-coco-tests-on-arm64 to nightly CI runs by gating on
inputs.pr-number == 'nightly'.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The shellcheck_required.yaml workflow now covers everything this
workflow did and more, running at severity=style instead of the
default severity.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
Raise the shellcheck gate from severity=error to severity=style now
that all scripts in the repo have been cleaned up. Ignore paths that
are being removed by other efforts.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
Address shellcheck warnings including proper variable quoting,
use of [[ ]] over [ ], declaring and assigning variables separately,
and adding appropriate shellcheck disable directives where needed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
Address shellcheck warnings including proper variable quoting,
use of [[ ]] over [ ], declaring and assigning variables separately,
and adding appropriate shellcheck disable directives where needed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
Address shellcheck warnings including proper variable quoting,
use of [[ ]] over [ ], declaring and assigning variables separately,
and adding appropriate shellcheck disable directives where needed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
Address shellcheck warnings including proper variable quoting,
use of [[ ]] over [ ], declaring and assigning variables separately,
and adding appropriate shellcheck disable directives where needed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Made-with: Cursor
