Let’s connect and hack together on nested virtualization in TDX.
I’d like us to explore whether we can run attestable containers in an attested TDX VM.
And whether we even should?
What good does it get us?
How does remote attestation even work in the context of nested virtualization?
Join us on 2024-06-11T14:00:00Z to help find the answers to those & many more TEE questions!
Should I install something on my machine to show up prepared?
Ideally you have Qemu, Docker, and Yocto set up.
canonical/tdx can be used to easily set up the development environment for Qemu (even if you don’t have access to TDX).
flashbots/yocto-manifests can be used as a guide to set up Yocto.
If you want to experiment with virtualization you might want to make sure you have access to a machine (or a VM) with KVM module enabled (see this KVM installation guide for example), although that’s not strictly necessary.
And whether we even should?
Why shouldn’t we? 
I think this is actually worth thinking about.
What do we gain that we don’t gain by simply running another TD? (cc @Quintus since you asked a similar question elsewhere).
Can we get the virtualization inside the TDX VM to be secure enough to be realistically useful?
I think right now we are simply exploring, and hopefully we find some unique properties enabled by nesting containers in TDX VMs
Here is the recording for any latecomers:
As I understand it, the two approaches are not mutually exclusive. We could run a few containers in one TD (or just a single one) and separate those even more thoroughly from containers in another TD.
My naive guess would be that we face a security vs. performance tradeoff in which cross-TD communication is expensive but lower level isolation is stronger
I think that’s absolutely correct. Using “single-container” TD for isolation between containers should get us really good guarantees on both what and how runs in the container, as well as good protection against other guests.
