TDX: Ensure Kata Containers can run on the main distros that have TDX support

[fidencio]

Let me start saying that this issue here is a mix of a braindump, with an ask for help. :-)

Intel has been collaborating with OSVs (Canonical, Red Hat, SUSE) in order to have TDX available on the host side in a way it can be easily used. On our CI, we've been using Ubuntu (from Canonical) or CentOS 9 Stream (from Red Hat), and I hope we'd be able to get one machine for each at some point.

However, distros have their own pace, they ship their own host kernel, and with a specific host kernel there are changes on what QEMU can and will support, together with the command line to be used with it, leading me to open this issue.

While I know that Kata Containers currently does not support any distro, and has zero distro specific code in its codebase, I'm wondering whether we could:

• Build a different QEMU TDX for different distros
• Decide which QEMU TDX to use based on the distro being used
• Build the command line accordingly based on the distro being used

This is not a beautiful approach, and ideally should be dropped as soon as the host kernel patches land upstream and distros adopt it. However, till it happens we really are looking for a way to provide users the ability to try Kata Containers for their specific distro.

While on this, another possible approach would be to rely on the host side components coming from the distro themselves, avoiding us to build QEMU TDX and TDVF. This would simplify things a little bit, but we'd still be on the same boat of having to adapt the QEMU command line according to the distro, and possibly also binary locations.

I'd like to start this conversation here and understand where the community (and the @kata-containers/architecture-committee) stand on this, allowing us to push Kata Containers (and Confidential Containers) to be used in the best possible way, by the maximum amount of distros we can support.

[fidencio]

/cc @chavafg

[zvonkok]

I have the very same situation with the GPU support. I need to run some workloads with 5.x kernels and some with 6.x kernels, both for SNP and TDX. This means that I currently have 3 different branches I am working off, and keeping them all in sync with the same feature set regarding the GPU is a huge pain.
How are we making sure that features are available in all those branches?
I suppose we're only concentrating on the 6.x (UPM, gmem) kernels?
How would a release look like? One release with all QEMUs packaged or different releases per OS?

[fidencio]

How are we making sure that features are available in all those branches?

My proposal is to focus on what the distros have, rather than in any kernel that's not yet upstreamed / close to.
The "problem" with vendor specific kernels is that what the vendor do not necessarily will land upstream, while the distros (which do have maintainers upstream) would be more selective on what they pick and ship.

I suppose we're only concentrating on the 6.x (UPM, gmem) kernels?

For TDX, I'd be focusing on "whatever" is in Ubuntu 24.04 and CentOS 9 Stream TDX SIG. Those 2 cases are quite close to 6.8 / 6.9 host kernels, plus TDX patches the distros are dealing with.

How would a release look like? One release with all QEMUs packaged or different releases per OS?

Actually, a release would look like NO QEMU / OVMF packaged. Just different configurations, like: configuration-qemu-tdx-ubuntu, and configuration-qemu-tdx-c9s, and kata-deploy would take care of figuring out which configuration would be used in the system being deployed. Then, the configuration file would use the QEMU / OVMF from the distro themselves.

Let me know if I was able to answer all your questions.

[fidencio]

like: configuration-qemu-tdx-ubuntu, and configuration-qemu-tdx-c9s

Thinking a little bit better about this, we don't need extra configuration files, we just need to properly adjust the path for the distro QEMU / OVMF in a dummy configuration-qemu-tdx.

[fidencio]

In the Kata Containers AC meeting held on May 7th, we agreed with this approach.
AC members who gave a thumbs up: Anastassions, Greg, Steve, Zvonko, We didn't get any pushback, as the other AC members where not present in the call (time was not the best for them).

[stevenhorsman]

In the Kata Containers AC meeting held on May 7th, we agreed with this approach. AC members who gave a thumbs up: Anastassions, Greg, Steve, Zvonko, We didn't get any pushback, as the other AC members where not present in the call (time was not the best for them).

Just to confirm this - and apologise that I didn't update this with that outcome like I intended.