The host KVM capability checks obtained the KVM_CREATE_VM and
KVM_CHECK_EXTENSION ioctl request numbers from <linux/kvm.h> via cgo
(kata-check.go for the generic check, hypervisor_linux_arm64.go for the
Arm RME check). This was the only remaining use of cgo in the runtime,
and it forced the runtime to be linked against the host libc.
Replacing these with plain Go constants lets kata-runtime,
containerd-shim-kata-v2 and kata-monitor build with CGO_ENABLED=0,
which is a prerequisite for producing fully static, libc-agnostic
binaries that run on musl-only hosts (the kata-deploy payload otherwise
fails to exec on a glibc-free distribution because its requested dynamic
loader is absent).
The ioctl numbers are stable kernel ABI. The asm-generic encoding used
by amd64, arm64, s390x and riscv64 gives _IO(KVMIO, nr) == (0xAE << 8) |
nr, while powerpc uses the legacy encoding (_IOC_NONE == 1, direction
shifted by 29). The values are split into kvm_ioctls_generic.go and
kvm_ioctls_ppc64le.go accordingly so each architecture keeps the exact
value its kernel headers would have produced.
No functional change: the runtime issues the same ioctls as before.
Signed-off-by: Dimitris Karakasilis <dimitris@spectrocloud.com>
Generated-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Migrate kata-types and kata-agent from toml 0.5 to 1.x:
- Consolidate kata-types onto the workspace toml version
- Replace toml::to_vec() (removed in 1.x) with to_string().into_bytes()
- Map toml::de::Error with .map_err(std::io::Error::other) where functions
return io::Result (From impl was removed in 1.x)
- Update test assertions: toml 1.x serializes strings with double quotes
instead of single quotes
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
No API changes required: Patch, PatchOperation, and patch() have
compatible signatures across the 2.x → 4.x range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Migrate hooks.rs from the removed Popen/PopenConfig/CommunicateError API
to the subprocess 1.x Exec/Job builder API:
- Replace Popen::create() + PopenConfig with Exec builder + Job
- communicate_start().read_string() → job.communicate()?.limit_time().read_string()
- read_string() now returns io::Result<(String,String)> (no Option wrapper)
- ExitStatus enum variants replaced with ExitStatus::code() / signal() methods
- Timeout errors propagated with io::ErrorKind::TimedOut as before
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update hyper to 1.10.1 and hyperlocal to 0.9.1 (required for hyper 1.x
compatibility). Add http-body-util 0.1, hyper-util 0.1 and bytes 1.0 as
workspace dependencies.
API changes applied across shim-interface, runtimes, hypervisor
(firecracker) and resource (nydus_client) crates:
- hyper::Body → http_body_util::Full<Bytes> for outgoing bodies
- hyper::body::Incoming for incoming server request bodies
- hyper::Client → hyper_util::client::legacy::Client
- hyper::Server + make_service_fn → TcpListener loop +
hyper_util::server::conn::auto::Builder (kata-ctl http_server)
- hyper::server::conn::Http → hyper::server::conn::http1::Builder
with hyper_util::rt::TokioIo wrapper (runtimes shim_mgmt server)
- hyper::body::to_bytes() → BodyExt::collect().await?.to_bytes()
- Client::unix() now requires explicit body type parameter Full<Bytes>
- Drop removed 'stream' feature flag from hyper dependency declarations
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Integrate virtio-mem into memory hotplug and hotunplug operations:
- Modified hotplug_memory() to automatically detect virtio-mem device
and use resize instead of pc-dimm hotplug
- Modified hotunplug_memory() to use virtio-mem resize for memory
decrease with saturating_sub to prevent underflow
- Modified hotplugged_memory_size() to account for virtio-mem devices
- Falls back to pc-dimm when virtio-mem is not available
This completes the virtio-mem integration, enabling dynamic memory
management with virtio-mem-ccw on s390x while maintaining full
backward compatibility with pc-dimm.
Assisted-by: IBM Bob
Signed-off-by: Annu Sharma <annu-sharma@ibm.com>
Call setup_virtio_mem() during VM startup when enable_virtio_mem flag
is set:
- Added setup call after QMP connection is established
- Proper error handling with context
Assisted-by: IBM Bob
Signed-off-by: Annu Sharma <annu-sharma@ibm.com>
When VFIO GPUs span both host NUMA nodes, emit guest NUMA nodes even
if vCPUs < node count (memory-only nodes), and pin each pxb-pcie to
bus=pcie.0 so QEMU does not attach the second expander to the first.
Also fix checkVCPUsPinningNUMA to tolerate vCPUs < NUMA node count.
The memory-only NUMA topology (emitted for pxb-pcie placement when
default_vcpus=1) creates more guest NUMA nodes than there are vCPUs;
the previous hard error silently tore down every sandbox. Now the
available vCPU(s) are pinned to the first node(s) and memory-only
nodes are skipped.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
The `hotplug_vfio_on_root_bus` configuration option is no longer needed
in the runtime-rs.
Remove the option from:
- `DeviceInfo` struct and its `hotplug_vfio_on_root_bus` field
- `PCIeTopology` struct and its construction in `topology.rs`
- `HypervisorInfo` struct and its `hotplug_vfio_on_root_bus` field
- `KATA_ANNO_CFG_HYPERVISOR_HOTPLUG_VFIO_ON_ROOT_BUS` annotation constant
and its handler in `Annotation::apply()`
- DragonBall validation check in `ConfigPlugin::adjust_config()`
- All runtime-rs TOML config templates (qemu, fc, nvidia GPU variants)
- Test fixture TOML files
Update the documentation having a reference to it.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Make the agent's handling of CoCo guest components data-driven so that a
new extension bundle can be introduced without changing agent code.
Add a new `extension` module defining a generic component manifest contract.
When a CoCo extension image is mounted at /run/kata-extensions/coco/, the agent
reads etc/kata-extensions/components.toml from it to discover:
- path-only components (looked up by id under the `[paths]` table), used
for the ocicrypt config and the pause bundle, and
- launchable processes (`[[process]]` entries) describing the binary
path, args, optional args, config file, environment, socket to wait on
and timeout.
`${var}` tokens in process fields are substituted from a fixed,
documented context the agent builds at runtime (attestation socket/uri,
config paths, rest-api features, initdata toml path, launch timeout,
resolved ocicrypt config path). Referencing an unknown variable is a
hard error, and manifest paths are validated against traversal, so the
contract stays fail-closed.
Processes are gated by a numeric `level` mapped from
guest_components_procs (AttestationAgent < ConfidentialDataHub <
ApiServerRest), preserving the existing implication semantics.
When no extension is mounted, launch_plan() returns None and the agent uses
a built-in plan that reproduces the legacy behaviour byte-for-byte
(binaries under /usr/local/bin, /etc/ocicrypt_config.json, /pause_bundle).
Monolithic / non-split confidential images are therefore unaffected.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
During the transition to composable (base + extension) CoCo images, run the
two runtimes on different image layouts so CI exercises both paths via
the existing qemu-{snp,tdx,coco-dev} (Go) and -runtime-rs (Rust) shims:
- runtime-rs (Rust) CoCo templates use the standard base image plus a
CoCo extension extra_image:
image = "@IMAGEPATH@" (was @IMAGECONFIDENTIALPATH@)
[[hypervisor.qemu.guest_extension_images]]
name = "coco"
path = "@COCOIMAGEPATH@"
verity_params = "@COCOVERITYPARAMS@"
COCOIMAGENAME/COCOIMAGEPATH/COCOVERITYPARAMS are added to the
runtime-rs Makefile only.
- runtime (Go) CoCo templates keep the monolithic confidential image
(@IMAGECONFIDENTIALPATH@) and pull rootfs-image-confidential.
shim-components.json reflects this: Go CoCo shims depend on
rootfs-image-confidential while the runtime-rs CoCo shims depend on
rootfs-image + rootfs-image-coco-extension.
shim-v2/build.sh feeds each runtime its own dm-verity params: Rust gets
the measured base image hash (@KERNELVERITYPARAMS@) plus the extension hash
(@COCOVERITYPARAMS@); Go gets the monolithic confidential image hash
(@KERNELVERITYPARAMS@). This is wired per make invocation so the same
@KERNELVERITYPARAMS@ placeholder resolves correctly for each.
Once the split path is validated we can flip the Go templates too and
drop the monolithic confidential image.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Add a systemd template unit kata-extension-mount@.service and companion
helper scripts (kata-extension-mount.sh, kata-extension-umount.sh) that handle
the guest-side setup of extension block device images.
The mount script:
- Discovers the block device by matching its virtio serial (extension-<name>)
- Reads verity parameters from kata.extension.<name>.verity_params on the
kernel command line
- Creates a dm-verity device and mounts the EROFS filesystem read-only
at /run/kata-extensions/<name>/
The unit uses ConditionKernelCommandLine=kata.extension.%i.verity_params so
it only activates when that extension is configured for the VM, and is
ordered before kata-agent.service so extension contents are available when
the agent starts.
A systemd generator (kata-extension-mount-generator) instantiates the
template for every kata.extension.<name>.verity_params entry on the kernel
command line. Because the runtime emits one such entry per configured
guest_extension_images, extensions are enabled purely from the cmdline and
adding a new one needs no change to the rootfs build.
The agent Makefile is updated to install the unit, scripts and generator.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Mirror the Rust runtime's guest_extension_images support in the Go runtime:
- hypervisor.go: add GuestExtensionImage struct and GuestExtensionImages field to
HypervisorConfig.
- config.go: parse [[hypervisor.qemu.guest_extension_images]] TOML sections
via toGuestExtensionImages(), validating that every extension has a non-empty
name and valid dm-verity parameters.
- qemu.go: in buildDevices(), attach each extra image as a virtio-blk
drive with ID extension-<name>; in kernelParameters(), append
kata.extension.<name>.verity_params=... for each extra image.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Add a serial_override field to BlockConfig and DeviceVirtioBlk so that
extension images get a deterministic QEMU serial (extension-<name>) instead of
the auto-generated image-<id>. This lets the guest discover each extension
via /dev/disk/by-id/virtio-extension-<name>.
Wire up the full cold-plug path for guest_extension_images:
- sandbox.rs: iterate boot_info.guest_extension_images, create read-only
BlockConfig entries with the correct serial_override, and push them
as ResourceConfig::GuestExtensionImage.
- resource lib.rs / manager_inner.rs: handle the new GuestExtensionImage variant
by delegating to the existing block device path.
- cmdline_generator.rs: use serial_override when present for the QEMU
serial= parameter; append kata.extension.<name>.verity_params=... to the
kernel command line for each extra image.
- inner.rs: propagate serial_override from BlockConfig to the cmdline
generator's add_block_device().
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Introduce the GuestExtensionImage type to describe extension block-device images
(e.g. CoCo guest components) that are cold-plugged into the VM
alongside the main rootfs.
Each GuestExtensionImage carries a short name (used as the virtio-blk serial
and in kernel cmdline verity parameters), a host-side path, and
dm-verity parameters (required -- extension images must be integrity-
protected).
A new guest_extension_images Vec is added to BootInfo so that both the Rust
and Go runtimes can iterate the configured extensions when building the
VM device list and kernel command line.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Bumps github.com/opencontainers/runc from v1.2.8 to v1.3.6 to fix
GHSA-xjvp-4fhw-gc47 (CVE, CVSS 4.8).
The libcontainer/cgroups/systemd sub-package was removed from runc in
v1.3.x and moved to the standalone github.com/opencontainers/cgroups
module. Update the import in pkg/resourcecontrol/utils_linux.go
accordingly, and promote github.com/opencontainers/cgroups to a direct
dependency.
Fixes: https://osv.dev/GHSA-xjvp-4fhw-gc47
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
ResizeVolumeRequest is declared in agent.proto and has a rules.rego
default entry, but the kata-agent had no corresponding ttrpc handler
in the AgentService impl block. This meant the CI policy-coverage
check (ci/check_agent_policy_coverage.sh) correctly flagged it as
ungated.
Add a resize_volume handler that:
- calls is_allowed(&req) so the policy boundary is enforced, and
- returns UNIMPLEMENTED, reflecting that the kata-agent has never
carried out volume resizes itself (runtime-rs exercises this RPC
via its own agent client; the kata-agent path was simply absent).
Generated-By: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Six AgentService RPC request types were missing default rule entries in
rules.rego, meaning genpolicy-generated policies would not include them
in their output and the entries would be absent from reference policies.
All six already have is_allowed gates in the agent RPC handlers.
Add the missing defaults and set them all to false
Generated-By: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Add default-deny entries for MemAgentMemcgConfig and MemAgentCompactConfig
to rules.rego, and the corresponding allow entries to the two reference
OPA policies (allow-all.rego and allow-all-except-exec-process.rego).
Generated-By: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump path-absolutize in rustjail from 1.2.1 to 3.1.1
Transitive dependency path-dedot is updated from 1.2.4 to 3.1.1,
which replaces the lazy_static dependency with once_cell, and the
slash-formatter dependency is dropped entirely.
Assisted-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update the workspace thiserror dependency to 2.0.18 and
normalize direct workspace crate pins to use the workspace
version.
Fix thiserror 2.x format-string breakage in Dragonball by
replacing mixed positional/implicit arguments in #[error(...)]
attributes with explicit named arguments.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
I'm not sure why we aren't catching this elsewhere, but
when running checks I saw the unused
import warning, so thought I would fix it
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
The mem_agent_memcg_set and mem_agent_compact_set handlers in rpc.rs
were the only AgentService methods that did not call is_allowed() before
executing. Because the policy engine was never consulted, no OPA/Rego
policy — including the strict default-deny policy generated by genpolicy
— could deny these requests.
Add is_allowed(&config).await? as the first statement of both handlers,
matching the pattern used by every other handler in the file.
Generated-By: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This commit enhances the VFIO-AP testing suite by adding
support for cold-plug testing in runtime-rs and updating
configuration files to support the new cold_plug_vfio parameter.
Changes include:
1. Configuration updates:
- Added cold_plug_vfio parameter to configuration-qemu-runtime-rs.toml.in
with default value "no-port" (disabled)
- Added cold_plug_vfio parameter to configuration-qemu-se-runtime-rs.toml.in
with value "root-port" (enabled for Secure Execution)
2. Test enhancements:
- Updated setup_hotplug() to explicitly set cold_plug_vfio to "no-port"
for runtime-rs to ensure hotplug-only mode
- Implemented setup_coldplug() for runtime-rs (previously unsupported)
to enable cold-plug testing with "root-port" configuration
- Added new test case (Test 4) for runtime-rs VFIO-AP cold-plug
functionality using zcrypttest validation
This enables comprehensive testing of both hot-plug and cold-plug VFIO
device assignment scenarios for s390x CEX devices in runtime-rs.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Add support for cold-plugging raw VFIO devices in standalone
container scenarios (e.g., `ctr --device /dev/vfio/0`) where
devices are specified directly in the OCI spec rather than
through K8S CDI/device plugins.
This implements a fallback path that:
- Reads linux.devices from the OCI spec in the container bundle
- Identifies character devices under /dev/vfio
- Cold-plugs them before VM boot using the configured cold_plug_vfio mode
- Handles VFIO-AP devices specially by using NoPort topology
- Mirrors the Go runtime's coldOrHotPlugVFIO() behavior
The implementation:
- Adds prepare_coldplug_raw_vfio_devices() method to VirtSandbox
- Exports is_vfio_ap_device() helper for device type detection
- Integrates with existing CDI device cold-plug flow
- Only activates when cold_plug_vfio is configured (not "no-port")
- Skips processing when bundle path is unavailable or OCI spec missing
Plus, update resource manager:
- Skipping hotplug for cold-plugged mediated AP devices
- Handling the AP devices to get exposed to the agent
This enables VFIO device passthrough for standalone containers while
maintaining compatibility with Kubernetes pod resource API workflows.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Add runtime-rs support for s390x VFIO-AP mediated devices across
QEMU device creation, hotplug/coldplug flows, and agent device
translation.
Introduce a dedicated vfio-ap QEMU device generator using the sysfsdev
path and route mediated AP devices through it instead of the PCI VFIO
path. Skip PCI-specific guest path handling for these devices since
they do not use PCI root ports or guest PCI addresses.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
This commit adds a fallback mechanism in `get_image_reference()` to
handle SingleContainer scenarios where no container type annotation
is present.
The issue occurs when standalone container runtimes (like nerdctl)
create containers without the Kubernetes container type annotation.
In such cases, `container_type_with_id()` returns `SingleContainer`
as the default, but `get_image_reference()` previously only checked
for image names when a container type annotation was explicitly set
to either PodSandbox or PodContainer.
This caused image reference lookups to fail for standalone containers,
even though the image name annotations (io.kubernetes.cri.image-name
or io.kubernetes.cri-o.ImageName) were present in the spec.
The fallback logic now checks for image name annotations directly
when no container type annotation is found, supporting both:
- io.kubernetes.cri.image-name (standard CRI)
- io.kubernetes.cri-o.ImageName (CRI-O specific)
This maintains backward compatibility with Kubernetes pod scenarios
while enabling support for standalone container runtimes that don't
provide container type annotations.
Test cases have been added to verify the fallback behavior for both
CRI and CRI-O image name annotations in SingleContainer scenarios.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Replace the encrypted-emptyDir boolean setting with an emptydir_type
setting that can describe shared-fs, block-encrypted, and block-plain
emptyDirs.
Add policy storage templates for block encrypted and block plain emptyDirs
with the create-filesystem driver option. Plain block emptyDirs also carry
the discard mount option. The block storage source pattern is relaxed to
match the runtime-rs values observed for block devices.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Teach the agent to create an ext4 filesystem for fresh block volumes
when the storage request carries the block create-filesystem driver
option.
The create-filesystem option is the freshness and format signal, while
storage.fstype remains the filesystem type source. Plain block emptyDirs
are formatted directly by the agent. Encrypted block emptyDirs must carry
the same create-filesystem signal together with ephemeral encryption and
continue through CDH secure_mount.
Reject ephemeral encryption without the create-filesystem signal so
existing direct block storage cannot accidentally enter the fresh emptyDir
path.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Pass block-device discard support through the runtime-rs QEMU stack.
Block device configuration now reaches both QEMU startup and hotplug
paths. The backend receives discard=unmap, and virtio-blk frontend
devices advertise discard support when requested. The SCSI hotplug path
keeps its existing frontend arguments.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Pass block-device discard support through the Go QEMU stack.
Block drives can now carry a DiscardUnmap request into govmm. QEMU
command-line and QMP hotplug paths set discard=unmap on the backend and
enable discard on virtio-blk frontends, while leaving SCSI frontend
arguments unchanged.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Add runtime-rs support for the block-plain emptyDir mode.
Disk-backed Kubernetes emptyDir mounts remain bind mounts so the block
emptyDir volume handler can intercept them. The handler creates a sparse
disk.img in the kubelet emptyDir directory, attaches it as a block device,
and rewrites the container mount to the agent-visible block storage path.
The same handler now covers encrypted and plain block emptyDirs. Fresh
block emptyDirs request filesystem creation through a dedicated metadata
flag. Plain emptyDirs add discard support, while encrypted emptyDirs keep
the existing ephemeral encryption metadata.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Add Go runtime support for the block-plain emptyDir mode.
Disk-backed Kubernetes emptyDir mounts remain bind mounts so the block
emptyDir handling path can intercept them. The runtime creates a sparse
disk.img in the kubelet emptyDir directory and records direct-volume
metadata for the agent-visible block storage path.
Fresh block emptyDirs request filesystem creation through a dedicated
metadata flag. Plain emptyDirs also record discard support on the block
device. Encrypted emptyDirs keep the existing ephemeral encryption
metadata and carry the same filesystem-creation signal.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Bump opentelemetry and opentelemetry-otlp from 0.27.0 to 0.32.0 to
align with the opentelemetry_sdk 0.32.1 upgrade. Adapt tracer.rs to
the breaking API changes introduced in that release.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Signed-off-by: dependabot[bot] <support@github.com>
The IBM SEL runtime requires a larger overhead_memory budget than
other TEE runtimes (SNP, TDX) because the kernel command line baked
into the SE image sets:
swiotlb=262144 (262144 × 2 KiB slots = 512 MiB)
This buffer is pre-allocated at boot from the guest's physical RAM
before any workload runs.
With static_sandbox_resource_mgmt = true the VM gets:
vm_memory = overhead_memory + container_limit
In k8s-limit-range.bats, DEFOVERHEADMEMSZ_TEE (128 MiB) resulted in
a 256 MiB VM when a container with a 128 MiB memory limit was scheduled
— far too small to even fit the swiotlb allocation, causing boot failure.
In a similar way, the failure is also observed for k8s-oom.bats.
Introduce DEFOVERHEADMEMSZ_TEE_SE := 768 MiB, sized to cover:
- 512 MiB swiotlb bounce buffer (fixed by sealed kernel cmdline)
- ~128 MiB SE kernel + initrd + agent baseline
- ~128 MiB headroom for other stuff
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Replace the agent's inline devicemapper implementation with the libs
kata-types::dmverity module. The agent's devicemapper Cargo feature
now forwards to kata-types/devicemapper, removing the direct
libdevmapper link dependency from the agent crate. Gate all dm-verity
imports, constants, and call sites behind libdevmapper.
Add USE_DEVMAPPER Makefile variable (default no) that appends the
devicemapper feature flag and forces LIBC=gnu when enabled.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
This commit is just a enhancement without any functionality changes.
Replace the sequential loop in handle_multi_layer_erofs_group with
join_all-based concurrent mounting. Base device paths and mount
directories are pre-resolved before spawning futures to avoid lock
contention. On partial failure, successfully mounted layers are
unmounted and dm-verity devices cleaned up before propagating the
error.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Introduce a new `dmverity` module in kata-types that provides dm-verity
device creation, destruction and lifecycle management via devicemapper
ioctls. The module is conditionally compiled behind the `devicemapper`
feature flag, which also pulls in tokio for async device-node polling.
The workspace devicemapper dependency is pinned to a specific git
revision for reproducible builds.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
