Temporarily disables the new runners for building artifacts jobs. Will be re-enabled once they are stable.
Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
This partially reverts 8dcd91c for the s390x because the
CI jobs are currently blocking the release. The new runners
will be re-introduced once they are stable and no longer
impact critical paths.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
This allows us to do a full multi-arch deployment, as the user can
easily select which shim can be deployed per arch, as some of the VMMs
are not supported on all architectures, which would lead to a broken
installation.
Now, passing shims per arch we can easily have an heterogenous
deployment where, for instance, we can set qemu-se-runtime-rs for s390x,
qemu-cca for aarch64, and qemu-snp / qemu-tdx for x86_64 and call all of
those a default kata-confidential ... and have everything working with
the same deployment.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The previous procedure failed to reliably ensure that all unused Device
Cgroups were completely removed, a failure consistently verified by CI
tests.
This change introduces a more robust and thorough cleanup mechanism. The
goal is to prevent previous issues—likely stemming from improper use of
Rust mutable references—that caused the modifications to be ineffective
or incomplete.
This ensures a clean environment and reliable CI test execution.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Build only from Ubuntu repositories do not mix with developer.nvidia.com
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Update tools/osbuilder/rootfs-builder/nvidia/nvidia_chroot.sh
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Migrate the k8s job to a different runner and use a long running cluster
instead of creating the cluster on every run.
Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
This will help immensely projects consuming the kata-deploy helm chart
to use configuration options added during the development cycle that are
waiting for a release to be out ... allowing very early tests of the
stack.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
By default, `kubectl exec` inherits some capabilities from the
container, which could pose a security risk in a confidential
environment.
This change modifies the agent policy to strictly enforce that any
process started via `ExecProcessRequest` has no Linux capabilities.
This prevents potential privilege escalation within an exec session,
adhering to the principle of least privilege.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
As in CoCo cases, the ApparmorProfile setting within runtime-go is set with None,
we should align it with runtime-go.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Temporarily disable the auto-generated Agent Policy on Mariner hosts,
to workaround the new test failures on these hosts.
When re-enabling auto-generated policy in the future, that would be
better achieved with a tests/integration/kubernetes/gha-run.sh change.
Those changes are easier to test compared with GHA YAML changes.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
If a ConfigMap has more than 8 files it will not be mounted watchable
[1]. However, genpolicy assumes that ConfigMaps are always mounted at a
watchable path, so containers with large ConfigMap mounts fail
verification.
This commit allows mounting ConfigMaps from watchable and non-watchable
directories. ConfigMap mounts can't be meaningfully verified anyway, so
the exact location of the data does not matter, except that we stay in
the sandbox data dirs.
[1]: 0ce3f5fc6f/docs/design/inotify.md (L11-L21)Fixes: #11777
Signed-off-by: Markus Rudy <mr@edgeless.systems>
Every now and then, in case a failure happens, helm leaves the secret
behind without cleaning it up, leading to issues in the consecutive
runs.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Aurélien has moved to a reliable mirror for our tests, but we missed
that our tools Dockerfiles could benefit from the same change, which is
added now.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Although we saw this happening, we expected it to NOT happen ...
As the kernel is not signed, but we expect it to be (the cached
version), then we're bailing. :-/
Let's ensure a full rebuild of kernels happen and we'll be good from
that point onwards.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Add TDX QGS quote-generation-socket TDX QEMU object params for
attestation to work in NVGPU+TDX environment.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
By doing this we can ensure that more than one instance of
nydus-snapshotter can be running inside the cluster, which is super
useful for doing A-B "upgrades" (where we install a new version of
kata-containers + nydus on B, while A is still running, and then only
uninstall A after making sure that B is working as expected).
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
We've been wrongly trying to set up the `${shim}` (as the qemu-snp, for
instance) as the hypervisor name in the kata-containers configuration
file, leading to an `tomlq` breaking as all the .hypervisors.qemu* shims
are tied to the `qemu` hypervisor, and it happens regardless of the shim
having a different name, or the hypervisor being experimental or not.
```sh
$ grep "hypervisor.qemu*" src/runtime/config/configuration-*
src/runtime/config/configuration-qemu-cca.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-coco-dev.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-nvidia-gpu-snp.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-nvidia-gpu-tdx.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-nvidia-gpu.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-se.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-snp.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu-tdx.toml.in:[hypervisor.qemu]
src/runtime/config/configuration-qemu.toml.in:[hypervisor.qemu]
$ grep "hypervisor.qemu*" src/runtime-rs/config/configuration-*
src/runtime-rs/config/configuration-qemu-runtime-rs.toml.in:[hypervisor.qemu]
src/runtime-rs/config/configuration-qemu-se-runtime-rs.toml.in:[hypervisor.qemu]
```
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
`tests` module inside `memcg` module should be gated behind `test`, add
`[#cfg(test)]` to make those tests work properly.
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Some tests from mem-agent requires root privilege, use
`skip_if_not_root` to skip those tests if they were not executed under
root user.
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Prefixing with `#[allow(clippy::type_complexity)]` to silence this
warning, the return type is documented in comments.
```console
error: very complex type used. Consider factoring parts into `type` definitions
--> mem-agent/src/mglru.rs:184:6
|
184 | ) -> Result<HashMap<String, (usize, HashMap<usize, MGenLRU>)>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity
= note: `-D clippy::type-complexity` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::type_complexity)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Manually fix `redundant_field_names ` clippy warning by testing equality
against 0 as suggested by rust 1.85.1, since `mem-agent` is now a member
of `libs` workspace.
```console
error: this comparison involving the minimum or maximum element for this type contains a case that is always true or always false
--> mem-agent/src/psi.rs:62:8
|
62 | if reader
| ________^
63 | | .read_line(&mut first_line)
64 | | .map_err(|e| anyhow!("reader.read_line failed: {}", e))?
65 | | <= 0
| |____________^
|
= help: because `0` is the minimum value for this type, the case where the two sides are not equal never occurs, consider using `reader
.read_line(&mut first_line)
.map_err(|e| anyhow!("reader.read_line failed: {}", e))? == 0` instead
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#absurd_extreme_comparisons
= note: `#[deny(clippy::absurd_extreme_comparisons)]` on by default
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Manually fix `redundant_field_names` clippy warning as suggested by rust
1.85.1, since `mem-agent` is now a member of `libs` workspace.
```console
error: redundant field names in struct initialization
--> mem-agent/src/memcg.rs:441:13
|
441 | numa_id: numa_id,
| ^^^^^^^^^^^^^^^^ help: replace it with: `numa_id`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_field_names
= note: `-D clippy::redundant-field-names` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::redundant_field_names)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Manually fix `manual_strip` clippy warning as suggested by rust 1.85.1,
since `mem-agent` is now a member of `libs` workspace.
```console
error: stripping a prefix manually
--> mem-agent/src/mglru.rs:284:29
|
284 | u32::from_str_radix(&content[2..], 16)
| ^^^^^^^^^^^^^
|
note: the prefix was tested here
--> mem-agent/src/mglru.rs:283:13
|
283 | let r = if content.starts_with("0x") {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_strip
= note: `-D clippy::manual-strip` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::manual_strip)]`
help: try using the `strip_prefix` method
|
283 ~ let r = if let Some(<stripped>) = content.strip_prefix("0x") {
284 ~ u32::from_str_radix(<stripped>, 16)
|
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Manually fix `field_reassign_with_default` clippy warning as suggested
by rust 1.85.1, since `mem-agent` is now a member of `libs` workspace.
```console
error: field assignment outside of initializer for an instance created with Default::default()
--> mem-agent/src/memcg.rs:874:21
|
874 | numa_cg.numa_id = numa;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
note: consider initializing the variable with `memcg::CgroupConfig { numa_id: numa, ..Default::default() }` and removing relevant reassignments
--> mem-agent/src/memcg.rs:873:21
|
873 | let mut numa_cg = CgroupConfig::default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#field_reassign_with_default
= note: `-D clippy::field-reassign-with-default` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::field_reassign_with_default)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `redundant_pattern_matching` clippy warning as suggested by rust
1.85.1, since `mem-agent` is now a member of `libs` workspace.
```console
error: redundant pattern matching, consider using `is_some()`
--> mem-agent/src/memcg.rs:595:40
|
595 | ... if let Some(_) = config_map.get_mut(path) {
| -------^^^^^^^--------------------------- help: try: `if config_map.get_mut(path).is_some()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_pattern_matching
= note: `-D clippy::redundant-pattern-matching` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::redundant_pattern_matching)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `needless_bool` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: this if-then-else expression returns a bool literal
--> mem-agent/src/memcg.rs:855:17
|
855 | / if configs.is_empty() {
856 | | true
857 | | } else {
858 | | false
859 | | }
| |_________________^ help: you can reduce it to: `configs.is_empty()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_bool
= note: `-D clippy::needless-bool` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::needless_bool)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `for_kv_map` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: you seem to want to iterate on a map's keys
--> mem-agent/src/memcg.rs:822:43
|
822 | for (single_config, _) in &secs_map.cgs {
| ^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#for_kv_map
help: use the corresponding method
|
822 | for single_config in secs_map.cgs.keys() {
| ~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `into_iter_on_ref` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: this `.into_iter()` call is equivalent to `.iter_mut()` and will not consume the `Vec`
--> mem-agent/src/memcg.rs:1122:27
|
1122 | for info in infov.into_iter() {
| ^^^^^^^^^ help: call directly: `iter_mut`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#into_iter_on_ref
= note: `-D clippy::into-iter-on-ref` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::into_iter_on_ref)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `legacy_numeric_constants` clippy warning as suggested by rust
1.85.1, since `mem-agent` is now a member of `libs` workspace.
```console
error: usage of a legacy numeric constant
--> mem-agent/src/compact.rs:132:47
|
132 | if self.config.compact_force_times == std::u64::MAX {
| ^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#legacy_numeric_constants
help: use the associated constant instead
|
132 | if self.config.compact_force_times == u64::MAX {
| ~~~~~~~~
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `single_component_path_imports` clippy warning as suggested by rust
1.85.1, since `mem-agent` is now a member of `libs` workspace.
```console
error: this import is redundant
--> mem-agent/src/mglru.rs:345:5
|
345 | use slog_term;
| ^^^^^^^^^^^^^^ help: remove it entirely
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_component_path_imports
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `from_str_radix_10` clippy warning as suggested by rust 1.85.1,
since `mem-agent` is now a member of `libs` workspace.
```console
error: this call to `from_str_radix` can be replaced with a call to `str::parse`
--> mem-agent/src/mglru.rs:29:14
|
29 | let id = usize::from_str_radix(words[1], 10)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `words[1].parse::<usize>()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#from_str_radix_10
= note: `-D clippy::from-str-radix-10` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::from_str_radix_10)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `needless_borrow` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: this expression creates a reference which is immediately dereferenced by the compiler
--> mem-agent/src/memcg.rs:1100:52
|
1100 | self.run_eviction_single_config(infov, &config)?;
| ^^^^^^^ help: change this to: `config`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `ptr_arg` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
--> mem-agent/src/memcg.rs:367:19
|
367 | psi_path: &PathBuf,
| ^^^^^^^^ help: change this to: `&Path`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg
= note: requested on the command line with `-D clippy::ptr-arg`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `crate_in_macro_def` clippy warning as suggested by rust 1.85.1,
since `mem-agent` is now a member of `libs` workspace.
```console
error: `crate` references the macro call's crate
--> mem-agent/src/misc.rs:12:22
|
12 | slog::error!(crate::misc::sl(), "{}", format_args!($($arg)*))
| ^^^^^ help: to reference the macro definition's crate, use: `$crate`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#crate_in_macro_def
= note: `-D clippy::crate-in-macro-def` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::crate_in_macro_def)]`
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `len_zero` clippy warning as suggested by rust 1.85.1, since
`mem-agent` is now a member of `libs` workspace.
```console
error: length comparison to zero
--> mem-agent/src/memcg.rs:225:61
|
225 | let (keep, moved) = vec.drain(..).partition(|c| c.numa_id.len() > 0);
| ^^^^^^^^^^^^^^^^^^^ help: using `!is_empty` is clearer and more explicit: `!c.numa_id.is_empty()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#len_zero
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Fix `bool_assert_comparison` clippy warning as suggested by rust 1.85.1,
since `mem-agent` is now a member of `libs` workspace.
```console
error: used `assert_eq!` with a literal bool
--> mem-agent/src/memcg.rs:1378:9
|
1378 | assert_eq!(m.get_timeout_list().len() > 0, true);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#bool_assert_comparison
= note: `-D clippy::bool-assert-comparison` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::bool_assert_comparison)]`
help: replace it with `assert!(..)`
|
1378 - assert_eq!(m.get_timeout_list().len() > 0, true);
1378 + assert!(m.get_timeout_list().len() > 0);
|
```
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
`mem-agent` now does not ship example binaries and serves as a library
for `agent` to reference, so we move it into `libs` to better manage it.
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
Auto-generate policy in k8s-optional-empty-secret.bats, now that
genpolicy suppprts optional secret-based volumes.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
We've recently added support for:
* deploying and setting up a snapshotter, via
_experimentalSetupSnapshotter
* enabling experimental_force_guest_pull, via
_experimentalForceGuestPull
However, we never updated the documentation for those, thus let's do it
now.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Downloading Go from storage.googleapis.com fails intermittently with a 403
(see error below) so we switch to go.dev as referenced at
https://go.dev/dl/.
/tmp/install-go-tmp.Rw5Q4thEWr ~/work/kata-containers/kata-containers
/usr/bin/go
[install_go.sh:85] INFO: removing go version go1.24.9 linux/amd64
[install_go.sh:94] INFO: Download go version 1.24.6
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 298 100 298 0 0 2610 0 --:--:-- --:--:-- --:--:-- 2614
[install_go.sh:97] INFO: Install go
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
[install_go.sh:99] ERROR: sudo tar -C /usr/local/ -xzf go1.24.6.linux-amd64.tar.gz
https://github.com/kata-containers/kata-containers/actions/runs/18602801597/job/53045072109?pr=11947#step:5:17
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
This change ensures that the NVIDIA package repository for nvidia-imex
and libnvidia-nspc is being used as source.
The NVIDIA repository does not publish these packages with a -580
version suffix, which made us fall back to the packages from the
Ubuntu repository.
These two packages were recently updated by Ubuntu to depend on
nvidia-kernel-common-580-server (this happened from version
580.82.07-0ubuntu1 to version 580.95.05-0ubuntu1). This conflicts
with nvidia-kernel-common-580 which gets installed by
nvidia-headless-no-dkms-580-open, thus causing a build failure.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
in CI helm is not yet installed and we don't have root access. Let's use
the current dir, which should be writable, and --no-sudo option to
install it.
Note when helm is installed it should not change anything and simply use
the syste-wide installation.
Signed-off-by: Lukáš Doktor <ldoktor@redhat.com>
While the local-build's folder's Makefile dependencies for the
confidential nvidia rootfs targets already declare the pause image
and coco-guest-components dependencies, the actual rootfs
composition does not contain the pause image bundle and relevant
certificates for guest pull. This change ensure the rootfs gets
composed with the relevant files.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
TOML was chosen for initdata particularly for the ability to include
policy docs and other configuration files without mangling them. The
default TOML encoding renders string values as single-line,
double-quoted strings, effectively depriving us of this feature.
This commit changes the encoding to use `to_string_pretty`, and includes
a test that verifies the desirable aspect of encoding: newlines are kept
verbatim.
Fixes: #11943
Signed-off-by: Markus Rudy <mr@edgeless.systems>
After supporting the Arm CCA, it will rely on the kernel kvm.h headers to build the
runtime. The kernel-headers currently quite new with the traditional one, so that we
rely on build the kernel header first and then inject it to the shim-v2 build container.
Signed-off-by: Kevin Zhao <kevin.zhao@linaro.org>
Co-authored-by: Seunguk Shin <seunguk.shin@arm.com>
The new initdata variants of the tests are failing on the tdx
runner, so as discussed, skip them for now: Issue #11945
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Now we have wider coverage of initdata testing in
k8s-guest-pull-image-signature.bats then remove
the old testing.
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Our current set of authenticated registry tests involve setting
kernel_params to config the image pull process, but as of
kata-containers#11197
this approach is not the main way to set this configuration and the agent
config has been removed. Instead we should set the configuration in the
`cdh.toml` part of the initdata, so add new test cases for this. In future, when
we have been through the deprecation process, we should remove the old tests
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Our current set of signature tests involve setting kernel_parameters to
config the image pull process, but as of
https://github.com/kata-containers/kata-containers/pull/11197
this approach is not the main way to set this configuration and the agent
config has been removed. Instead we should set the configuration in the
`cdh.toml` part of the initdata, so add new test cases for this. In future, when
we have been through the deprecation process, we should remove the old tests
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Create a shared get_initdata method that injects a cdh image
section, so we don't duplicate the initdata structure everywhere
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
One problem that we've been having for a reasonable amount of time, is
containerd not behaving very well when we have multiple snapshotters.
Although I'm adding this test with my "CoCo" hat in mind, the issue can
happen easily with any other case that requires a different snapshotter
(such as, for instance, firecracker + devmapper).
With this in mind, let's do some stability tests, checking every hour a
simple case of running a few pre-defined containers with runc, and then
running the same containers with kata.
This should be enough to put us in the situation where containerd gets
confused about which snapshotter owns the image layers, and break on us
(or not break and show us that this has been solved ...).
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
With this change we namespace the stage one rootfs tarball name
and use the same name across all uses. This will help overcome
several subtle local build problems.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
We fix the following error:
```
thread 'sandbox::tests::add_and_get_container' panicked at src/sandbox.rs:901:10:
called `Result::unwrap()` on an `Err` value: Create cgroupfs manager
Caused by:
0: fs error caused by: Os { code: 17, kind: AlreadyExists, message: "File exists" }
1: File exists (os error 17)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
by ensuring that the cgroup path is unique for tests run in the same millisecond.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Use CDI exclusively from crates.io and not from a GH repository.
Cargo can easily check if a new version is available and we can
far more easier bump it if needed.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
with the shellcheck fixes we accidentally quoted the "-n NAMESPACE"
argument where we should have used array instead, which lead to oc
considering this as a pod name and returning error.
Signed-off-by: Lukáš Doktor <ldoktor@redhat.com>
We need to ensure that any change on the Dockerfile (and its dir) leads
to the build being retriggered, rather than using the cached version.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
We are seeing more protoc related failures on the new
runners, so try adding the protobuf-compiler dependency
to these steps to see if it helps.
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
- copy default-initdata.toml in create_tmp_policy_settings_dir, so it can be modified by other tests if needed
- make auto_generate_policy use default-initdata.toml by default
- add auto_generate_policy_no_added_flags, so it may be used by tests that don't want to use default-initdata.toml by default
Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
On commit 9602ba6ccc, from February this
year, we've introduced a check to ensure that the files needed for
signing the kernel build are present. However, we've noticed last week
that there were a reasonable amount of wrong assumptions with the
workflow. :-)
Zvonko fixed the majority of those, but this bit was left and it'd cause
breakages when using kernel that was cached ... although passing when
building new kernels.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
This is needed to the kernel setup picks up the correct
config values from our fragments directories.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
We need to make sure that the kernel we're using has the
correct configs set, otherwise the module signing will not work.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Now that we have added the ability to deploy kata-containers with
experimental_force_guest_pull configured, let's make sure we test it to
avoid any kind of regressions.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Otherwise we have no way to differentiate running tests on qemu-coco-dev
with different snapshotters.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
What was done in the past, trying to set the env var on the same step
it'd be used, simply does not work.
Instead, we need to properly set it through the `env` set up, as done
now.
We're also bumping the kata_config_version to ensure we retrigger the
kernel builds.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
We have some scalable s390x and ppc runners, so
start to use them for build and test, to improve
the throughput of our CI
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Co-authored-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
For some reason we didn't have the "Report tests" step as part of the
TEE jobs. This step immensely helps to check which tests are failing and
why, so let's add it while touching the workflow.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
There's no reason to have the code duplication between the SNP / TDX
tests for CoCo, as those are basically using the same configuration
nowadays.
Note that for the TEEs case, as the nydus-snapshotter is deployed by the
admin, once, instead of deploying it on every run ... I'm actually
removing the nydus-snapshotter steps so we make it clear that those
steps are not performed by the CI.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
As virtio-scsi has been set the default block device driver, the
runtime also need to correctly handle the virtio-scsi info, specially
the SCSI address required within kata-agent handling logic.
And getting and assigning the scsi_addr to kata agent device id
will be enough. This commit just do such work.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Since runtime-rs support the block device hotplug with
creating new containers, and the device would also be
removed when the container stopped, thus add the block
device unplug for clh.
Signed-off-by: Fupan Li <fupan.lfp@antgroup.com>
This commit introduces support for selecting `virtio-scsi` as the
block device driver for QEMU during initial setup.
The primary goal is to resolve a conflict in non-TEE environments:
1. The global block device configuration defaults to `virtio-scsi`.
2. The `initdata` device driver was previously designed and hardcoded
to `virtio-blk-pci`.
3. This conflict prevented unified block device usage.
By allowing `virtio-scsi` to be configured at cold boot, the `initdata`
device can now correctly adhere to the global setting, eliminating the
need for a hardcoded driver and ensuring consistent block device
configuration across all supported devices (excluding rootfs).
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
The implementation of the seccomp feature in Dragonball currently has a basic framework.
But the actual restriction rules are empty.
This pull request includes the following changes:
- Modifiy configuration files to relevant configuration files.
- Modifiy seccomp framework to support different restrictions for different threads.
- Add new seccomp rules for the modified framework.
This commit primarily implements the changes 1 and 3 for runtime-rs.
Fixes: #11673
Signed-off-by: wangxinge <wangxinge@bupt.edu.cn>
For DGX like systems we need additional binaries and libraries,
enable the Kata AND CoCo use-case.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Update tools/osbuilder/rootfs-builder/nvidia/nvidia_rootfs.sh
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Fix all instances of template injection by using environment variables as
recommended by Zizmor, instead of directly injecting values into the
commands.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
The two ignored cases are strictly necessary for the CI to work today, and we
have various security mitigations in place.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
There are 62 such warnings and addressing them would take quite a bit of
time so just disable them for now.
help[undocumented-permissions]: permissions without explanatory comments
--> ./.github/workflows/release.yaml:71:7
|
71 | packages: write
| ^^^^^^^^^^^^^^^ needs an explanatory comment
72 | id-token: write
| ^^^^^^^^^^^^^^^ needs an explanatory comment
73 | attestations: write
| ^^^^^^^^^^^^^^^^^^^ needs an explanatory comment
|
= note: audit confidence → High
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
We can't test this PR because the workflow needs this trigger, so adding
this will allow testing future PRs.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
For those who are not willing to use the nydus-snapshotter for pulling
the image inside the guest, let's allow them setting the
experimetal_force_guest_pull, introduced by Edgeless, as part of our
helm-chart.
This option can be set as:
_experimentalForceGuestPull: "qemu-tdx,qemu-coco-dev"
Which would them ensure that the configuration for `qemu-tdx` and
`qemu-coco-dev` would have the option enabled.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
As the kata-deploy helm chart has been the only way we've been testing
kata-containers deployment as part of our CI, it's time to finally get
rid of the kustomize yamls and avoid us having to maintain two different
methods (with one of those not being tested).
Here I removed:
* kata-deploy yamls and kustomize yamls
* kata-cleanup yamls and kustomize yamls
* kata-rbac yals and kustomize yamls
* README.md for the kustomize yamls was removed
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
erofs-snapshotter can be used to leverage sharing the image from the
host to the guest without the need of a shared filesystem (such as
virtio-fs or virtio-9p).
This case is ideal for Confidential Computing enabled on Kata
Containers, and we can immensely benefit from this snapshotter, thus
let's test it as soon as possible so we can find issues, report bugs,
and ask for enhancement requests.
There are at least a few things that we know for sure to be problematic
now:
* Policy has to be adjusted to the erofs-snapshotter
* There is no support for signed nor encrypted images
* Tests that use the KBS are disabled for now
Even with the limitations, I do believe we should be testing the
snapshoitter, so we can team up and get those limitations addressed.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
As done in the previous commit, let's expand the vanilla k8s deployment
to also allow the erofs host side configuration.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
We already have support for deploying a few flavours of k8s that are
required for different tests we perform.
Let's also add the ability to deploy vanilla k8s, as that will be very
useful in the next commits in this series.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The active version is 2.1.x, and the latest is 2.2.0-beta.0.
The latest is what we'll be using to test if the "to be released"
version of containerd works well for our use-cases.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Let's make sure that we can get non-official releases as well, otherwise
we won't be able to test a coming release of containerd, to know whether
it solves issues that we face or not, before it's actually released.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
NVRC introduced the confidential feature flag and we
haven't updated the rootfs build to accomodate.
If rootfs_type==confidential user --feature=confidential
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Canonical TDX release is not needed for vanilla Ubuntu 25.10 but
GRUB_CMDLINE_LINUX_DEFAULT needs to contain `nohibernate` and
`kvm_intel.tdx=1`
Signed-off-by: Szymon Klimek <szymon.klimek@intel.com>
Use grep_pod_exec_output to retry possible failing "kubectl exec"
commands. Other tests have been hitting such errors during CI in
the past.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
This adds an integration test to verify that privileged containers work
properly when deploying Kata with kata-deploy.
This is a follow-up to #11878.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
Let's rely on kata-deploy setting up the nydus snapshotter for us,
instead of doing this with external code.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
This allows us to stop setting up the snapshotter ourselves, and just
rely con kata-deploy to do so.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Let's expose the EXPERIMENTAL_SETUP_SNAPSHOTTER script environment
variable to our chart, allowing then users of our helm chart to take
advantage of this experimental feature.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
We may deploy in scenarios where we want to have both snapshotters set
up, sometimes even for simple test on which one behaves better.
With this in mind, let's allow EXTERNAL_SETUP_SNAPSHOTTER to receive a
comma separated list of snapshotters, such as:
```
EXPERIMENTAL_SETUP_SNAPSHOTTER="erofs,nydus"
```
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Similarly to what's been done for the nydus-snapshotter, let's allow
users to have erofs-snapshotter set up by simply passing:
```
EXPERIMENTAL_SETUP_SNAPSHOTTER="erofs".
```
Mind that erofs, although a built-in containerd snapshotter, has system
depdencies that we will *NOT* install and it's up to the admin to do so.
These dependencies are:
* erofs-utils
* fsverity
* erofs module loaded
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
In the previous commit we added the assumption that the
nydus-snapshotter version should be the same in two different places.
Now, with this test, we ensure those will always be in sync.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Let's introduce a new EXPERIMENTAL_SETUP_SNAPSHOTTER environemnt
variable that, when set, allows kata-deploy to put the nydus snapshotter
in the correct place, and configure containerd accordingly.
Mind, this is a stop gap till the nydus-snapshotter helm chart is ready
to be used and behaving well enough to become a weak dependency of our
helm chart. When that happens this code can be deleted entirely.
Users can have nydus-snapshotter deployed and configured for the
guest-pull use case by simply passing:
```
EXPERIMENTAL_SETUP_SNAPSHOTTER="nydus"
```
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Otherwise we'd end up adding a the file several times, which could lead
to problems when removing the entry, leading to containerd not being
able to start due to an import file not being present.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The code, how it was, would lead to the following broke command:
`--header "Authorization: Bearer: "`
Let's only expand that part of the command if ${GH_TOKEN} is passed,
otherwise we don't even bother adding it.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Document that privileged containers with
privileged_without_host_devices=false are not generally supported.
When you try the above, the runtime will pass all the host devices to Kata
in the OCI spec, and Kata will fail to create the container for various
reasons depending on the setup, e.g.:
- Attempting to hotplug uninitialized loop devices.
- Attempting to remount /dev devices on themselves when the agent had
already created them as default devices (e.g. /dev/full).
- "Conflicting device updates" errors.
- And more...
privileged_without_host_devices was originally created to support
Kata [1][2] and lots of people are having issues when it's set to
false [3].
[1] https://github.com/kata-containers/runtime/issues/1568
[2] https://github.com/containerd/cri/pull/1225
[3] https://github.com/kata-containers/kata-containers/issues?q=is%3Aissue%20%20in%3Atitle%20privileged
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
We have noticed in the CI that the `gen_init_cpio ...` was returning 255
and breaking the build. Why? I am not sure.
When chatting with Steve, he suggested to split the command, so it'd be
easier to see what's actually breaking. But guess what? There's no
breakage when we split the command.
So, let's try it out and see whether the CI passes after it.
If someone is willing to educate us on this one, please, that would be
helpful! :-)
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Moving the CUDA repo to the top for all essential packages
and adding a repo priority favouring NVIDIA based repos.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Introduce new test case which verifies that openvpn clients and servers
can run as Kata pods and can successfully establish a connection.
Volatile certificates and keys are generated by an initialization
container and injected into the client and server containers.
This scenario requires TUN/TAP support for the UVM kernel.
Signed-off-by: Manuel Huber <mahuber@microsoft.com>
Co-authored-by: Manuel Huber <manuelh@nvidia.com>
No need to die when a Kind that does not require a policy annotation is
found in a pod manifest. Print an informational message instead.
Signed-off-by: Manuel Huber <mahuber@microsoft.com>
Currently, use of openvpn clients/servers is not possible in Kata UVMs.
Following error message can be expected:
ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
To support opevpn scenarios using bridging and TAP, we enable various
kernel networking config options.
Signed-off-by: Manuel Huber <mahuber@microsoft.com>
Manually added "hostPath" to main.txt then regenerated the dictionary
with `./kata-spell-check.sh make-dict`.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
This change crystallizes and simplifies the current handling of /dev
hostPath mounts with virtually no functional change.
Before this change:
- If a mount DESTINATION is in /dev and it is a non-regular file on the HOST,
the shim passes the OCI bind mount as is to the guest (e.g.
/dev/kmsg:/dev/kmsg). The container rightfully sees the GUEST device.
- If the mount DESTINATION does not exist on the host, the shim relies on
k8s/containerd to automatically create a directory (ie. non-regular file) on
the HOST. The shim then also passes the OCI bind mount as is to the guest. The
container rightfully sees the GUEST device.
- For other /dev mounts, the shim passes the device major/minor to the guest
over virtio-fs. The container rightfully sees the GUEST device.
After this change:
- If a mount SOURCE is in /dev and it is a non-regular file on the HOST,
the shim passes the OCI bind mount as is to the guest. The container
rightfully sees the GUEST device.
- The shim does not anymore rely on k8s/containerd to create missing mount
directories. Instead it explicitely handles missing mount SOURCES, and
treats them like the previous bullet point.
- The shim no longer uses virtio-fs to pass /dev device major/minor to the
guest, instead it passes the OCI bind mount as is.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
test_add_one_arp_neighbor modifies the root network namespace, so we
should ensure that it does not interfere with normal network setup.
Adding an IP to a device results in automatic routes, which may affect
routing to non-test endpoints. Thus, we change the addresses used in the
test to come from TEST-NET-1, which is designated for tests and usually
not routable.
Signed-off-by: Markus Rudy <mr@edgeless.systems>
list_routes and test_add_one_arp_neighbor have been flaky in the past
(#10856), but it's been hard to tell what exactly is going wrong.
This commit adds debug information for the most likely problem in
list_routes: devices being added/removed/modified concurrently.
Furthermore, it adds the exit code and stderr of the ip command, in case
it failed to list the ARP neighborhood.
Signed-off-by: Markus Rudy <mr@edgeless.systems>
The previous code only checked the result of with_nix_path(), not statfs(),
thus leading to an uninitialized memory read if statfs() failed.
No functional change otherwise.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
85f3391bc added the support for TDX QGS port=0 but missed
defaultQgsPort in the default config. defaultQgsPort overrides
user provided tdx_quote_generation_service_socket_port=0.
After this change, defaultQgsPort is not needed anymore since
there's no default: any positive integer is OK and negative or
unset value becomes a parse error.
QEMUTDXQUOTEGENERATIONSERVICESOCKETPORT in the Makefile is used
to provide a sane default when tdx_quote_generation_service_socket_port
gets set in the configuration.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
genpolicy is a developer tool that should be usable on MacOS. Adding it
to the darwin CI job ensures that it can still be built after changes.
On an Apple M2, the output of `uname -m` is `arm64`, which is why a new
case is needed in the arch_to_* functions.
We're not going to cross-compile binaries on darwin, so don't install
any additional Rust targets.
Fixes: #11635
Signed-off-by: Markus Rudy <mr@edgeless.systems>
Most of the kata-types code is reusable across platforms. However, some
functions in the mount module require safe-path, which is Linux-specific
and can't be used on other platforms, notably darwin.
This commit adds a new feature `safe-path` to kata-types, which enables
the functions that use safe-path. The Linux-only callers kata-ctl and
runtime-rs enable this feature, whereas genpolicy only needs initdata
and does not need the functions from the mount module. Using a feature
instead of a target_os restriction ensures that the developer experience
for genpolicy remains the same.
Signed-off-by: Markus Rudy <mr@edgeless.systems>
This commit adds changes to enable fs sharing between host/guest
using virtio-fs when booting a pod VM for testing. This primarily
enables sharing container rootfs for testing container lifecycle
commands.
Summary of changes is as below:
- adds minimal virtiofsd code to start userspace daemon (based on
`runtime-rs/crates/resource/src/share_fs`)
- adds the virtiofs device to the test vm
- prepares and mounts the container rootfs on host
- modifies container storage & oci specs
Signed-off-by: Sumedh Alok Sharma <sumsharma@microsoft.com>
Fixing the shellcheck issues first so that they are not coupled to the
subsequent commit introducing Darwin support to the script.
Signed-off-by: Markus Rudy <mr@edgeless.systems>
Auto-generate policy for nginx-deployment pods, instead of hard-coding
the "allow all" policy.
Note that the `busybox_pod` - created using `kubectl run` - still
doesn't have an Init Data annotation, so it is using the default policy
built into the Kata Guest rootfs image file.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
Auto-generate agent policy in k8s-liveness-probes.bats, instead of using
the non-confidential "allow all" policy.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
Auto-generate the agent policy for pod-secret-env.yaml, using
"genpolicy -c inject_secret.yaml".
Support for passing Secret specification files as "-c" arguments of
genpolicy has been added when fixing #10033 with PR #10986.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
Since we cannot build all components with libc=musl and
static RUSTFLAG we still need to ship libcc for AA or other guest
components.
Without this change the guest components do not work and we see
/usr/local/bin/attestation-agent: error while loading shared
libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
This fixes that error everywhere by adding a `name:` field to all jobs that
were missing it. We keep the same name as the job ID to ensure no
disturbance to the required job names.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
-o pipefail in particular ensures that exec_host() returns the right exit
code.
-u is also added for good measure. Note that $BATS_TEST_DIRNAME is set by
bats so we move its usage inside the function.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
As a consequence of moving away from Advanced Security for Zizmor, it now
checks the entire codebase and will error out on this PR and future.
To be reverted once we address all Zizmor findings in a future PR.
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
This PR fixes a test that failed on platforms like ppc64le due to a hardcoded mount option length.
* Test was failing on ppc64le due to larger system page size (e.g., 65536 bytes)
* Original test used a hardcoded 4097-byte string assuming 4KB page size
* Replaced with *MAX_MOUNT_PARAM_SIZE + 1 to reflect actual system limit
* Ensures test fails correctly across all architectures
Fixes: #11852
Signed-off-by: shwetha-s-poojary <shwetha.s-poojary@ibm.com>
The Hadolint warning DL3007 (pin the version explicitly) is no
longer applicable.
We have updated the base image to use a specific version
digest, which satisfies the linter's requirement for reproducible
builds. This commit removes the corresponding inline ignore comment.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
This change enables to run the QEMU VMM using a non-root user when rootless flag is set true in the configuration.
Signed-off-by: stevenfryto <sunzitai_1832@bupt.edu.cn>
This commit introduces generic support for running the VMM in rootless mode in runtime-rs:
1.Detect whether the VMM is running in rootless mode.
2.Before starting the VMM process, create a non-root user and launch the VMM with that user’s UID and GID; also add the KVM user's group ID to the VMM process's supplementary groups so the VMM process can access /dev/kvm.
3.Add the setup of the rootless directory located in the dir /run/user/<uid> directory, and modify some path variables to be functions that return the path with the rootless directory prefix when running in rootless mode.
Fixes: #11414
Signed-off-by: stevenfryto <sunzitai_1832@bupt.edu.cn>
We recently hit the following error during build:
```
RUN ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -P ""
OpenSSL version mismatch. Built against 3050003f, you have 30500010
```
This happened because `alpine:latest` moved forward and the `ssh-keygen`
binary in the base image was compiled against a newer OpenSSL version
that is not available at runtime.
Pinning the base image to the stable release (3.20) avoids the mismatch
and ensures consistent builds.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
This change fixes clean up logic when running tests
in a vm booted with qemu wrt to qmp.sock & console.sock
files, and no longer assumes any path for them.
Signed-off-by: Sumedh Alok Sharma <sumsharma@microsoft.com>
Change the default block driver to virtio-scsi.
Since the latest qemu's commit:
https://gitlab.com/qemu-project/qemu/-/commit/
984a32f17e8dab0dc3d2328c46cb3e0c0a472a73
brings a bug for virtio-blk-pci with io_uring mode at line:
https://gitlab.com/qemu-project/qemu/-/commit/
984a32f17e8dab0dc3d2328c46cb3e0c0a472a73#
ce8eeb01f8b84f8cb8d3c35684d473fe1ee670f9_345_352
In order to avoid this issue, change the default block driver
to virtio-scsi.
Signed-off-by: Fupan Li <fupan.lfp@antgroup.com>
As OCI Spec annotation has been updated with adding or remove items,
we should use the updated annotation as the passed argument.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
This commit removes the InitData annotation from the OCI Spec's
annotations.
Similar to the Policy annotation, InitData is now exclusively handled
and transmitted to the guest via the sandbox's init data mechanism.
Removing this redundant and potentially large annotation simplifies the
OCI Spec and streamlines the guest initialization process.
This change aligns the handling of InitData with existing practices
within runtime-go.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
The repro below would show this error in the logs (in debug mode only):
fatal runtime error: IO Safety violation: owned file descriptor already closed
The issue was that the `pseudo.slave` file descriptor was being owned by
multiple variables simultaneously. When any of those variables would go out
of scope, they would close the same file descriptor, which is undefined
behavior.
To fix this, we clone: we create a new file descriptOR that refers to the same
file descriptION as the original. When the cloned descriptor is closed, this
affect neither the original descriptor nor the description. Only when the last
descriptor is closed does the kernel cleans up the description.
Note that we purposely consume (not clone) the original descriptor with
`child_stdin` as `pseudo` is NOT dropped automatically.
Repro
-----
Prerequisites:
- Use Rust 1.80+.
- Build the agent in debug mode.
$ cat busybox.yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- image: busybox:latest
name: busybox
runtimeClassName: kata
$ kubectl apply -f busyboox.yaml
pod/busybox created
$ kubectl exec -it busybox -- sh
error: Internal error occurred: Internal error occurred: error executing
command in container: failed to exec in container: failed to start exec
"e6c602352849647201860c1e1888d99ea3166512f1cc548b9d7f2533129508a9":
cannot enter container 76a499cbf747b9806689e51f6ba35e46d735064a3f176f9be034777e93a242d5,
with err ttrpc: closed
Fixes: #11054
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
Log how much time "kubectl get pods" and each test case are taking,
just in case that will reveal unusually slow test clusters, and/or
opportunities to improve tests.
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
`allow_interactive_exec` requires a sandbox-name annotation, however
this is only added for pods by genpolicy. Other pod-generating resources
have unpredictable sandbox names.
This patch instead uses a regex for the sandbox name in genpolicy, based
on the specified metadata and following Kubernetes' naming logic. The
generated regex is then used in the policy to correctly match the
sandbox name.
Fixes: #11823
Signed-off-by: Charlotte Hartmann Paludo <git@charlotteharludo.com>
Co-authored-by: Paul Meyer <katexochen0@gmail.com>
Co-authored-by: Markus Rudy <mr@edgeless.systems>
@@ -450,7 +450,7 @@ You can build and install the guest kernel image as shown [here](../tools/packag
# Install a hypervisor
When setting up Kata using a [packaged installation method](install/README.md#installing-on-a-linux-system), the
`QEMU` VMM is installed automatically. Cloud-Hypervisor, Firecracker and StratoVirt VMMs are available from the [release tarballs](https://github.com/kata-containers/kata-containers/releases), as well as through [`kata-deploy`](../tools/packaging/kata-deploy/README.md).
`QEMU` VMM is installed automatically. Cloud-Hypervisor, Firecracker and StratoVirt VMMs are available from the [release tarballs](https://github.com/kata-containers/kata-containers/releases), as well as through [`kata-deploy`](../tools/packaging/kata-deploy/helm-chart/README.md).
You may choose to manually build your VMM/hypervisor.
To enhance security, Kata Containers supports using seccomp to restrict the hypervisor's system calls. Previously, this was only supported for a subset of hypervisors in runtime-go. Now, the runtime-rs also supports seccomp. This document describes how to enable/disable the seccomp feature for the corresponding hypervisor in runtime-rs.
## Pre-requisites
1. Ensure your system's kernel supports **seccomp**.
2. Confirm that each of the following virtual machines can run correctly on your system.
## Configure seccomp
With the exception of `qemu`, seccomp is enabled by default for all other supported hypervisors. Their corresponding built-in functionalities are also enabled by default.
### QEMU
As with runtime-go, you need to modify the following in your **configuration file**. These parameters will be passed directly to the `qemu` startup command line. For more details on the parameters, you can refer to: [https://www.qemu.org/docs/master/system/qemu-manpage.html](https://www.qemu.org/docs/master/system/qemu-manpage.html)
``` toml
# Qemu seccomp sandbox feature
# comma-separated list of seccomp sandbox features to control the syscall access.
# For example, `seccompsandbox= "on,obsolete=deny,spawn=deny,resourcecontrol=deny"`
# Note: "elevateprivileges=deny" doesn't work with daemonize option, so it's removed from the seccomp sandbox
# Another note: enabling this feature may reduce performance, you may enable
# /proc/sys/net/core/bpf_jit_enable to reduce the impact. see https://man7.org/linux/man-pages/man8/bpfc.8.html
The **seccomp** functionality is enabled by default for the following three hypervisors: `cloud hypervisor`, `firecracker`, and `dragonball`.
The seccomp rules for `cloud hypervisor` and `firecracker` are built directly into their executable files. For `dragonball`, the relevant configuration is currently located at `src/runtime-rs/crates/hypervisor/src/dragonball/seccomp.rs`.
To disable this functionality for these hypervisors, you can modify the following configuration options in your **configuration file**.
``` toml
# Disable the 'seccomp' feature from Cloud Hypervisor, firecracker or dragonball, default false
disable_seccomp = true
```
## Implementation details
For `qemu`, `cloud hypervisor`, and `firecracker`, their **seccomp** functionality is built into the respective executable files you are using. **runtime-rs** simply provides command-line arguments for their launch based on the configuration file.
For `dragonball`, a set of allowed system calls is currently provided for the entire **runtime-rs** process, and the process is prevented from using any system calls outside of this whitelist. As mentioned above, this set is located at `src/runtime-rs/crates/hypervisor/src/dragonball/seccomp.rs`.
@@ -6,4 +6,4 @@ Container deployments utilize explicit or implicit file sharing between host fil
As of the 2.0 release of Kata Containers, [virtio-fs](https://virtio-fs.gitlab.io/) is the default filesystem sharing mechanism.
virtio-fs support works out of the box for `cloud-hypervisor` and `qemu`, when Kata Containers is deployed using `kata-deploy`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](../../tools/packaging/kata-deploy/README.md#kubernetes-quick-start).
virtio-fs support works out of the box for `cloud-hypervisor` and `qemu`, when Kata Containers is deployed using `kata-deploy`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](../../tools/packaging/kata-deploy/helm-chart/README.md).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
