Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton
Dear Anton, during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV. Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable. [1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687 [2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code [3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22 Kind regards, Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support
Best Regards, Anton
-- Markus Hentsch DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 00 markus.hentsch@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann
A few more points to add... * You probably need https://blueprints.launchpad.net/nova/+spec/libvirt-firmware-auto-selection to be implemented first for your work, so that an appropriate firmware with TDX support is selected during instance creation. * One mechanism we still have to implement for AMD SEV-SNP is an interface to allow users to pass down some additional fields such as hostData from api to actual guest domain. We don't really want that interface to be quite specific to a single technology and want it to be generic enough to cover multiple ones. However honestly I'm struggling to understand the requirements in TDX long after I played with it, and I'm unsure how we can make that interface "generic". If you can give some details about the required parameters for confidential computing use case with TDX that may be helpful to enhance that discussion. On 1/20/26 1:58 AM, Markus Hentsch wrote:
Dear Anton,
during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV.
Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable.
[1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687
[2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
[3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22
Kind regards,
Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support
Best Regards, Anton
On 1/19/26 18:56, Takashi Kajinami wrote:
A few more points to add...
* You probably need https://blueprints.launchpad.net/nova/+spec/libvirt- firmware-auto-selection to be implemented first for your work, so that an appropriate firmware with TDX support is selected during instance creation.
Yes that is definitely needed! Since it is planned for 2026.1 release could I effectively treat it as implemented in the TDX spec? Happy to help with reviews here to make sure it works as expected for TDX.
* One mechanism we still have to implement for AMD SEV-SNP is an interface to allow users to pass down some additional fields such as hostData from api to actual guest domain. We don't really want that interface to be quite specific to a single technology and want it to be generic enough to cover multiple ones. However honestly I'm struggling to understand the requirements in TDX long after I played with it, and I'm unsure how we can make that interface "generic". If you can give some details about the required parameters for confidential computing use case with TDX that may be helpful to enhance that discussion.
Is the aim to provide a generic interface for all additional fields or just the hostData field? The latter is very doable, but all fields will be harder to make generic. From the TDX point of view there are 5 fields of interest, see libvirt spec [1]. mrConfigId, mrOwner and mrOwnerConfig have similar purposes to hostData in SNP, but are slightly larger (48-bytes each) and specific. Due to the size difference a common approach is to only look at the lower 32 bytes, thus unifying it with hostData. [4] contains some descriptions of the specific use cases of these 3 fields. It can be argued that both mrConfigId and mrOwnerConfig fit semantically. Azure [2] and Confidential Containers [3] do for example use the SHA256 hash digest for their init/host data interface and use mrConfigId in the TDX case. My suggestion is to do the same to keep it consistent across implementations. Remaining fields: The policy field in TDX is pretty much the as the one in SNP but the bits have different meaning. The quoteGenerationService is unique to TDX and a requirement for attestation. [1] https://libvirt.org/formatdomain.html#launch-security [2] https://learn.microsoft.com/en-us/rest/api/attestation/attestation/attest-tdx-vm?view=rest-attestation-2025-06-01&tabs=HTTP#inittimedata [3] https://github.com/confidential-containers/confidential-containers/issues/17... [4] https://lore.kernel.org/qemu-devel/31d6dbc1-f453-4cef-ab08-4813f4e0ff92@inte...
On 1/20/26 1:58 AM, Markus Hentsch wrote:
Dear Anton,
during the last PTG (project team gathering) there was some discussion about future extensions to the confidential computing support in Nova, not limited to just SEV-SNP [1]. As a result, there is currently ongoing work on extending the architecture to prepare for supporting multiple vendor's technologies [2][3], for example Intel TDX and ARM CCA, in addition to AMD SEV.
Maybe you could help with reviewing the patchsets to ensure that the architecture changes will work for TDX and/or join in there at some point and contribute to the TDX-specific side of things directly. I think that either would be very valuable. Great to see that TDX is already planned for. Glad to join in on reviews until TDX specifics are needed.
[1] https://etherpad.opendev.org/p/nova-2026.1-ptg#L687
[2] https://blueprints.launchpad.net/nova/+spec/generalize-sev-code
[3] https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22
Kind regards,
Markus
Hi,
I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova.
I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release.
From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed.
Early feedback or any concerns and guidance are very welcome!
[1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt- support
Best Regards, Anton
participants (3)
-
Anton Iacobaeus
-
Markus Hentsch
-
Takashi Kajinami