enable start container from bundle in this way
$ ls ./bundle
config.json rootfs
$ sudo ctr run -d --runtime io.containerd.kata.v2 --config bundle/config.json test_kata
Fixes:#5872
Signed-off-by: Zhongtao Hu <zhongtaohu.tim@linux.alibaba.com>
Fixed formatting for check release options
Fixes: #5345
Signed-off-by: Alex <alee23@bu.edu>
Signed-off-by: David Esparza <david.esparza.borquez@intel.com>
This is to enable quay.io/confidential-containers/runtime-payload for
s390x on top of amd64.
Fixes: #5894
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
The client side is moved to libs. This is to solve the problem
that including clients will bring about messy dependencies.
Fixes: #5874
Signed-off-by: Ji-Xinyou <jerryji0414@outlook.com>
In order to avoid building the containerd binaries on every single run
of our CI, let's simply rely on the fact that now we're releasing the
"same" artefacts containerd normally releases from our own fork.
See:
https://github.com/confidential-containers/containerd/releases/tag/v1.6.8.1Fixes: #5895
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Add some new ignore items to avoid local builds that cause git to track a lot of files
Fixes: #5900
Signed-off-by: Binbin Zhang <binbin36520@gmail.com>
When `HOST_ARCH` != `ARCH` unset `CC`
Specifying a foreign CC is incompatible with building libgit2. Thus after the RUSTFLAGS linker
has been set we can safely unset CC to avoid passing this value through the build.
Fixes: #5890
Signed-off-by: James Tumber <james.tumber@ibm.com>
After building the binary as usual with `cargo build` run it as follows.
It needs a configuration.toml in which only qemu keys `path`, `kernel`
and `initrd` will initially need to be set. Point them to respective
files e.g. from a kata distribution tarball.
It also needs to be launched from an exported container bundle
directory. One can be created by running
mkdir rootfs
podman export $(podman create busybox) | tar -C ./rootfs -xvf -
runc spec -b .
in a suitable directory.
Then launch the program like this:
KATA_CONF_FILE=/path/to/configuration-qemu.toml /path/to/shim-ctl
Fixes: #5817
Signed-off-by: Pavel Mores <pmores@redhat.com>
This does almost literally nothing so far apart from getting and setting
HypervisorConfig. It's mostly copied from/inspired by dragonball.
Signed-off-by: Pavel Mores <pmores@redhat.com>
DEFAULT_REGISTRY pre-registers many metrics that we don't need or have duplicated.
This PR uses a custom register for metrics without interference and ensures that
the registration process is executed only once when the program is running.
Fixes: #5255
Signed-off-by: Yuan-Zhuo <yuanzhuo0118@outlook.com>
In order to let upcall being used by Kata Container, we need to add
those patches into kernel build script.
Currently, only when experimental (-e) and hypervisor type dragonball
(-t dragonball) are both enabled, that the upcall patches will be
applied to build a 5.10 guest kernel.
example commands: sh ./build-kernel.sh -e -t dragonball -d setup
fixes: #5642
Signed-off-by: Chao Wu <chaowu@linux.alibaba.com>
Upcall is a direct communication tool between VMM and guest developed
upon vsock. The server side of the upcall is a driver in guest kernel
(kernel patches are needed for this feature) and it'll start to serve
the requests after the kernel starts. And the client side is in
Dragonball VMM , it'll be a thread that communicates with vsock through
uds.
We want to keep the lightweight of the VM through the implementation of
the upcall, through which we could achieve vCPU hotplug, virtio-mmio
hotplug without implementing complex and heavy virtualization features
such as ACPI virtualization.
fixes: #5642
Signed-off-by: Chao Wu <chaowu@linux.alibaba.com>
If `loop` module is not probed, it causes error like "losetup: cannot find an unused loop device".
Fixes: #5887
Signed-off-by: Guoqiang Ding <dgq8211@gmail.com>
As done for different components, let's also use a cached version of the
shim-v2 whenever it's possible.
Fixes: #5838
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
In order to cache the shim-v2 we're considering the the cached component
can be used if:
* There were no changes in the runtime directory
* There were no changes in the golang version used
* There were no changes in the rust version used
* We don't build the rust agent, but better be prepared for the future
* There were no changes in the following files that are provided by the
rootfs builds:
* root_hash_vanilla.txt
* root_hash_tdx.txt
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As done for different components, let's also use a cached version of
the rootfs whenever it's possible.
Fixes: #5433
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
e1f075dc60 reworked the action so the
shim-v2 was split out of the matrix build. With that done I ended up
not realising I'd need to log into the quay.io as one step of the
build-asset-cc-shim-v2 job.
Fixes: #5885
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is the most complex part to cache, as the cached component can be
only used if:
* There were no changes in the agent
* There were no changes in the libs (used by the agent)
* There were no changes in the rootfs build scripts
* There is no change in the version of the following components:
* attestation-agent (part of the rootfs)
* gperf (used to build libseccomp)
* libseccomp (used to build the agent)
* pause image (part of the rootfs)
* skopeo (part of the rootfs)
* umoci (part of the rootfs)
* rust (used to build the kata-containers and attestation agents)
We're relying on the last commit merged on places related to the rootfs
generation and using that as the rootfs version and that should be good
enough for what we need.
Apart from everything already mentioned, we've also added the ability to
cache the `root_hash_vanilla.txt` and `root_hash_tdx.txt` files, as
those are needed for when building the shim-v2, in order to have
measured boot working there.
It's important to note that we've added the ability to cache *both*
files, and I've taken that path as the shim-v2 cache work (which will
come soon) relies on both files.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This will help us, in the future, to debug any possible issue related to
the measured rootfs arguments passed to the shim during the build time.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The ability to do a measured boot has been overlooked when releasing the
payload consumed by the Confidential Containers project, and this
happened as we depend, at the shim-v2 build time, of a `root_hash_*.txt`
generated in the `tools/osbuilder/` directory, which is then used to add
a specific parameter to the `kernel_params` in the Kata Containers
configuration files.
With everything said above, the best way we can ensure this is done is
by saving those files during the rootfs build, download them during the
shim-v2 build (which *must* happen only after the rootfs builds happen),
and correctly use them there.
Fixes: #5847
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As Cloud Hypervisor and QEMU are using different rootfs images (the
former with `offline_fs_kbc` as aa_kbc, and the latter with `eaa_kbc`),
we need to differentiate the kernel parameters passed to each one of
those, as the `root_hash.txt` file used for measured boot will differ
according to the rootfs used.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
