Teach the shim-v2 build to feed the "nvidia" base root hash into the Go
runtime's KERNELVERITYPARAMS_NV_BASE - its KERNELVERITYPARAMS_NV is the
monolithic nvidia-gpu hash - so qemu-nvidia-cpu boots the base image
verity-backed just like qemu-nvidia-cpu-runtime-rs already does.
List the new qemu-nvidia-cpu / qemu-nvidia-cpu-runtime-rs classes in
shim-components.json so the build ships them: both boot the nvidia base
image with the nvidia kernel and no GPU extension, dropping OVMF on x86_64
and keeping it on aarch64 (which boots via UEFI).
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
qemu-nvidia-gpu boots the driver-agnostic NVIDIA base image and then
cold-plugs the GPU extension on top. Nothing, however, just boots that
base image on NVIDIA hosts that have no GPU (or where the GPU isn't handed
to the guest), even though the base image is perfectly usable on its own.
Add qemu-nvidia-cpu (Go) and qemu-nvidia-cpu-runtime-rs (Rust), cloned
from the qemu-nvidia-gpu configs with every GPU-passthrough bit dropped:
no guest_extension_images, cold_plug_vfio = "no-port", pcie_root_port = 0,
no VFIO pod-resource wiring and no GPU NUMA validation. Resource defaults
and timeouts are pulled back in line with qemu[-runtime-rs] (1 vCPU,
DEFMEMSZ, small overheads) rather than the GPU-tuned values, and firmware
is left to the arch default so x86_64 boots without OVMF.
Both classes boot the measured nvidia base image verity-backed. The Rust
runtime already maps KERNELVERITYPARAMS_NV to the base hash; the Go runtime
maps it to the monolith, so a dedicated KERNELVERITYPARAMS_NV_BASE var is
added for qemu-nvidia-cpu.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Under static_sandbox_resource_mgmt the VM is sized to exactly what OCI
requests (base default_vcpus plus workload CPU limits) and CPU hotplug is
off, so DefaultMaxVCPUs is set to the sized NumVCPUs().
When a pod requests default_vcpus=0 with no CPU limit, that sized count
rounds to 0. DefaultMaxVCPUs then becomes 0, which the hypervisor later
expands to the host maximum (govmm.MaxVCPUs()). With NUMA enabled the SMP
topology becomes sockets=maxcpus=host_max, e.g. maxcpus=240, which fails
to boot on hosts where KVM caps the recommended vCPU count (the sandbox
never comes up and k8s-sandbox-vcpus-allocation / k8s-cpu-ns time out on
qemu-nvidia-cpu).
A VM cannot boot with zero vCPUs (QEMU already clamps -smp to 1), so floor
DefaultMaxVCPUs at that same single boot vCPU rather than falling back to
the host maximum. This keeps the value equal to the OCI-requested count in
every non-degenerate case and never consults the host maximum under static
management.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
When containerd wants to terminate a container, it sends a KillRequest with exec_id="", all=false, signal=SIGTERM.
Kata-shim translates that to a SignalProcessRequest with exec_id="", signal=SIGTERM
Kata agent used to interpret exec_id="" as implying all=true.
That was correct for forceful deletion of containers, as it uses a KillRequest with all=true, signal=SIGKILL.
However, for graceful termination, we want to only signal the root process of the container (all=false).
This changes makes it so that Kata agent interprets exec_id="" && signal=SIGKILL as implying all=true, and uses all=false otherwise.
It also fixes an unrelated bug, where Kata agent would signal the root process twice when all=true.
Fixes#13152 - sending SIGTERM twice to the container's init process on graceful shutdown of a container.
Signed-off-by: Bozhidar Marinov <bozhidar.marinov1@digits.schwarz>
Co-authored-by: Markus Rudy <webmaster@burgerdev.de>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
The `kbs-client` installation step was timing out at 10 minutes on
the downgraded zVSI profile (4 vCPU x 8 GB). Double the timeout to
20 minutes to accommodate the slower build/download speed on this
instance profile.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
3 trusted-storage guest-pull tests require a pod that demands
more CPU than is available on the downgraded zVSI profile
(4 vCPU x 8 GB) used for IBM Cloud s390x CI, causing scheduling
to fail with:
```
1 Insufficient cpu. no new claims to deallocate, preemption: 0/1 nodes
are available: 1 No preemption victims found for incoming pod.
```
Skip all three tests when running on s390x with KATA_HYPERVISOR=qemu-coco-dev*
to avoid false failures on this instance profile.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
The latest version is failing to install with the below error, so pin to
the last known good version.
WARNING: No stable version of 'aks-preview' to install. Preview versions allowed.
ERROR: The checksum of the extension does not match the expected value. Use --debug for more information.
Evidence this version fixes the issue locally:
$ az extension list-versions --name aks-preview --output table | tail -2
True False True (upgrade available) aks-preview True 21.0.0b8
True False False aks-preview True 21.0.0b9 (max compatible version)
$ az extension add --name aks-preview --version 21.0.0b9
No stable version of 'aks-preview' to install. Preview versions allowed.
The checksum of the extension does not match the expected value. Use --debug for more information.
$ az extension remove --name aks-preview
The extension aks-preview is not installed. Please install the extension via `az extension add -n aks-preview`.
$ az extension add --name aks-preview --version 21.0.0b8
No stable version of 'aks-preview' to install. Preview versions allowed.
The installed extension 'aks-preview' is in preview.
$
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
The proposal told us to move it under docs/design/ once it was accepted
and implemented. The systemd base landed on main and the NVIDIA split
(nvidia base + gpu extension) is what this series wires up, so it's no
longer a proposal - promote it to docs/design/composable-vm-images.md,
flip the status accordingly and repoint the in-tree references (agent,
osbuilder and kata-deploy) at the new path.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
createContainer hooks run in the forked container child, where kata-agent's
async slog drain (its background thread) does not exist, so `error!` from a
failing hook is silently dropped and the failure leaves no trace at all.
Mirror hook failures to /dev/kmsg, the one log sink that survives the fork
and reaches the guest console, so a hook that can't be found or exits
non-zero is at least visible when debugging. Failures only.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Hooks were spawned by PATH-searching `args[0]`. After `env_clear()` a bare
argv[0] only resolves against the compiled-in default PATH (/bin:/usr/bin),
so a hook binary living elsewhere - e.g. a composable-image extension under
/run/kata-extensions/<name>/bin - failed to start with ENOENT.
Execute the hook's `path` instead (an absolute path, already validated in
`new`), passing `args` as argv with argv[0] = args[0]. This matches OCI
runtime-spec semantics and lets hooks run from any location.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Add the rootfs-image-nvidia-{base,gpu-extension} build targets to the
local-build Makefile and the nvgpu bundle.
Build the base/extension rootfs images in the amd64/arm64 static tarball
workflows, and point the runtime-rs NVIDIA shim components at the
composable base + gpu extension (+ coco extension for the confidential
classes). The Go shim components keep the monolithic nvidia-gpu /
nvidia-gpu-confidential images.
Ship cryptsetup in the CoCo guest-components extension (and bundle
libnvat's non-glibc dependency closure next to the nvidia attester): the
chiseled nvidia base image carries only veritysetup, so the coco-extension
manifest's usr/sbin PATH entry needs a cryptsetup to resolve for NVIDIA
confidential encrypted-storage.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Flip the runtime-rs NVIDIA GPU configs (plain/tdx/snp) from the monolithic
image to the driver-agnostic nvidia base boot image plus a cold-plugged,
driver-versioned gpu extension mounted at /run/kata-extensions/gpu.
Confidential runtime-rs configs additionally cold-plug the CoCo
guest-components extension and enforce the nvidia base dm-verity hash.
The Go runtime keeps booting the monolithic nvidia-gpu / nvidia-gpu-confidential
images, mirroring the CoCo split where runtime-rs is the first-class citizen and
Go stays on the monolithic layout.
Add the IMAGE{NAME,PATH}_NV_{BASE,EXTENSION} and NVIDIAGPUEXTENSIONVERITYPARAMS
make vars (runtime-rs only), and read the nvidia base + gpu-extension root
hashes into runtime-rs's shim-v2 opts while the Go opts keep reading the
monolithic nvidia-gpu / nvidia-gpu-confidential hashes.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Carve the monolithic NVIDIA GPU rootfs into a driver-agnostic
nvidia base image (NVRC init + agent + base libs + in-tree modules)
and a driver-versioned gpu extension (GPU userspace, configs, firmware,
NVIDIA modules) laid out for /run/kata-extensions/gpu. Both halves are
produced from the same chiseled tree via a partition-after step, so
the monolith build stays byte-identical and continues to ship.
The shared stage-one (driver install) is reused across the monolith,
base and extension variants; nvidia base is cached without the driver/ctk
versions so one base image can back multiple driver extensions.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
We've been carrying a full, 1200+ line busybox .config for the NVIDIA
images. That's a pain to review and to keep in sync with a busybox
bump, as basically every default that changes upstream ends up as noise
in our file.
Switch to shipping only the handful of options we actually care about in
a small fragment and let busybox's own Kconfig fill in the rest at build
time: start from allnoconfig, drop the baseline entries for whatever the
fragment overrides (Kconfig keeps the first value it reads), append the
fragment and run silentoldconfig. This reproduces the exact same
.config we had frozen, module loading included, so there's no functional
change here.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
NVRC v0.1.5 carries the guest-side extension mounting that the composable
NVIDIA GPU images will rely on.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
The InfiniBand and Mellanox mlx5 options used to be carried (as modules)
in the NVIDIA GPU config fragments. They're now enabled built-in by the
common mlx5.conf fragment, which every kernel build already picks up, so
keeping them here is redundant - and the =m entries here only end up
fighting the built-in =y ones from the common fragment.
Drop the HGX/DGX block from both the x86_64 and arm64 GPU fragments and
bump kata_config_version so the kernel is rebuilt.
Assisted-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Fixes RUSTSEC-2026-0190 — unsoundness in anyhow::Error::downcast_mut()
in versions < 1.0.103.
We do not call anyhow::Error::downcast_mut() anywhere in the codebase,
so we are not directly exploiting the unsound path, but the bump is
applied to eliminate the advisory from cargo-audit output.
Ref: https://osv.dev/RUSTSEC-2026-0190
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Fixes RUSTSEC-2026-0204 — unsoundness in crossbeam-epoch < 0.9.20.
crossbeam-epoch is a transitive dependency pulled in via:
crossbeam 0.8.4 → ttrpc 0.8.6
No direct dependency changes are needed; pinning the resolved version
in Cargo.lock is sufficient to ensure the fixed crate is used.
Ref: https://osv.dev/RUSTSEC-2026-0204
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Fixes RUSTSEC-2026-0194 and RUSTSEC-2026-0195 reported against
quick-xml < 0.37.2. The quick-xml se::to_string API used by kata-ctl's
log-parser is unchanged between 0.28 and 0.41, so no call-site edits
are needed.
Ref: https://osv.dev/RUSTSEC-2026-0194
Ref: https://osv.dev/RUSTSEC-2026-0195
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump workspace rstest to 0.26.1 and migrate local pins in
kata-types and kata-ctl to workspace = true. No macro API
changes required across this range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Add awaitgroup to workspace dependencies at 0.7.0 and switch both
rustjail and virt_container from local pins to workspace = true.
No API changes required — WaitGroup::new(), .worker() and .wait()
are unchanged across this range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump workspace sha2 to 0.11.0 and migrate the local pins in
src/agent/Cargo.toml and src/libs/kata-types/Cargo.toml to
workspace = true. No API changes required — the Digest trait
interface is unchanged across this range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Add sysinfo to the workspace dependencies at 0.39.5 and switch
kata-types from its local pin to workspace = true. No API changes
required — System::new_all() is stable across this range.
sysinfo 0.39.5 requires rustc >= 1.95. Update the workspace
rust-version to match the toolchain already set in rust-toolchain.toml.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Remove the local 0.13.0 pin and defer to the workspace version (0.22).
Migrate all callsites from the deprecated free-function API to the
engine-based API introduced in 0.20:
base64::encode(x) -> STANDARD.encode(x)
base64::decode(x) -> STANDARD.decode(x)
base64::encode_config(x, STANDARD) -> STANDARD.encode(x)
base64::decode_config(x, STANDARD) -> STANDARD.decode(x)
base64::encode_config(x, URL_SAFE) -> URL_SAFE.encode(x)
Add `use base64::Engine as _` to bring the trait methods into scope in
initdata.rs and mount.rs.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Replace the kustomize-based Trustee deployment with the upstream Trustee
Helm chart (deployment/helm-chart) for every platform, including TDX and
s390x, which the previous iteration still left on kustomize. The chart
deploys KBS, AS and RVPS as three separate images, so versions.yaml pins
image_kbs/image_as/image_rvps (from the upstream staged-images registry)
alongside the trustee revision, and bumps trustee to a build that carries
the IBM SE material mounting support and the SHA-512 report-data change.
guest-components is bumped in lockstep so IBM SE attestation agrees on the
SHA-512 runtime-data digest.
KBS runs with authorization_mode = "AuthenticatedAuthorization", so admin
requests from kbs-client carry the bearer token minted by the chart's
bootstrap job instead of relying on an anonymous, allow-all admin API. As
reused CI runners may still carry a kbs-client from an older Trustee that
predates the --admin-token-file flag, the client is rebuilt from the pinned
sources unless the installed one already understands it.
On the Intel TDX CI runner only the Attestation Service reaches the public
Intel DCAP collateral endpoint, so it is the sole component that needs the
corporate proxy. We set https_proxy on the AS alone: the KBS <-> AS <-> RVPS
traffic is plain HTTP/gRPC and in-cluster, and routing it through the proxy
breaks those connections. The Intel DCAP and NVIDIA verifiers are configured
by the chart out of the box, so TDX and SNP need no extra verifier knobs.
For IBM SE (s390x) the SE verifier now runs inside the gRPC Attestation
Service, so the SE materials are mounted on the AS Pod (not KBS) through the
chart's as.ibmse.* knobs, which create a node-local PV/PVC. The AS runs as a
non-root user with CAP_DAC_OVERRIDE dropped, hence fsGroup=1000 and a
group-readable hdr.bin so it can read the mounted materials.
The chart's default CPU requests reserve more of the small single-node CI
runners than the old single-Pod deployment did, starving test workloads that
ask for a couple of Guaranteed CPUs. Trustee requests are shrunk (limits kept
generous) so those Pods schedule again.
Debug logging is enabled on all components (log_level=debug) to ease
triaging attestation / resource-retrieval failures in CI, and the release is
rolled out with 'helm upgrade --install' so re-runs on long-lived CI
clusters reconcile in place.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Some are format expectation changes in 1.95, but
I think some are just missing fmts that our CI doesn't
check.
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Remove redundant `.into_iter()` call on `zip()` argument in
`multi_layer_erofs.rs`, as flagged by the new
`clippy::useless_conversion` lint in Rust 1.95.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Replace manual `if us != 0` guard before integer division with
`checked_div` as flagged by the new `clippy::manual_checked_ops` lint
in Rust 1.95.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Replace manual `if us != 0` guard before integer division with
`checked_div` as flagged by the new `clippy::manual_checked_ops` lint
in Rust 1.95.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Remove redundant `.into_iter()` call in `Vec::from_iter()` argument in
dragonball and firecracker's `inner_hypervisor.rs`, as flagged by the new
`clippy::useless_conversion` lint in Rust 1.95.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Rust 1.95's clippy introduces new `collapsible_match` lints for `if`
blocks nested inside match arms that can be expressed as match guards.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Rust 1.95's clippy introduces new `collapsible_match` lints for `if`
blocks nested inside match arms that can be expressed as match guards.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Rust 1.95's clippy introduces new `collapsible_match` lints for `if`
blocks nested inside match arms that can be expressed as match guards.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
When 1.97 has been released, in compliance with our toolchain guidance
we should bump to rust 1.95
Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
The CLH runtime-rs config template uses @CONFIG_CLH_IN@ in its
source-file comment, but CONFIG_CLH_IN was missing from the generated
template variables.
Add it to USER_VARS so the generated config records the template path
instead of keeping the literal placeholder.
Fixes: #12941
Signed-off-by: WaterWhisperer <waterwhisperer24@qq.com>
