Confidential VM and TDX support in upstream Openstack
Hi, I'm reaching out about a topic that came up in the Kata Containers / Confidential Containers communities related to a feature in Kata that is called remote hypervisor and also referred to as peer pods. Kata provides an API that allows users to implement a function to run Kata Containers pods in a remote location, which can include a different host machine or cloud environment. The Cloud API Adaptor in the Confidential Containers project is an implementation of the Kata remote hypervisor interface: https://github.com/confidential-containers/cloud-api-adaptor It recently came up to add support for OpenStack to be a cloud option to run Kata remote VMs in. In order to implement that, OpenStack would need to support the creation of Confidential VMs (CVM) along with things like TDX. I looked around and found 3rd-party implementation to add TDX support to Nova, but the repo has been archived: https://github.com/intel/secured-cloud-management-stack/blob/main/scm3.0/nov... Does anyone know if the CVM support along with supporting Intel TDX or related technologies have been added to OpenStack already? Or if there's anyone in the community planning for adding these in the future? Thanks and Best Regards, Ildikó
The only TEE currently supported is AMD-SEV. I've been working on adding AMD SEV-ES support[1][2] and was planning to support AMD SEV-SNP on top of SEV-ES support, but the proposed patches to AMD SEV-ES support have been stuck due to limited review bandwidth in nova. [1] https://blueprints.launchpad.net/nova/+spec/amd-sev-es-libvirt-support [2] https://review.opendev.org/q/topic:bp/amd-sev-es-libvirt-support I've not yet looked into TDX quite in detail because it was not really upstream-ed at the time when I was working on SEV-ES support, but as far as I know TDX is based on similar concepts as SEV. So I think the good approach is to land SEV-ES support first and start working on adding SEV-SNP support as well as Intel TDX support based on the base mechanism added as part of SEV-ES support. Honestly speaking I've been struggling to gather attention about the work but if there are anyone also interested in this area and are willing to help, that would be really helpful to move forward these works. There was a discussion in the past nova PTG about adding support for Intel SGX, but unfortunately I've seen no progress about it. However I think we can leave it now assuming you are more interested in vm-based TEE, rather than application-based TEE. On 2/25/25 12:55 PM, Ildiko Vancsa wrote:
Hi,
I'm reaching out about a topic that came up in the Kata Containers / Confidential Containers communities related to a feature in Kata that is called remote hypervisor and also referred to as peer pods.
Kata provides an API that allows users to implement a function to run Kata Containers pods in a remote location, which can include a different host machine or cloud environment. The Cloud API Adaptor in the Confidential Containers project is an implementation of the Kata remote hypervisor interface: https://github.com/confidential-containers/cloud-api-adaptor
It recently came up to add support for OpenStack to be a cloud option to run Kata remote VMs in. In order to implement that, OpenStack would need to support the creation of Confidential VMs (CVM) along with things like TDX. I looked around and found 3rd-party implementation to add TDX support to Nova, but the repo has been archived: https://github.com/intel/secured-cloud-management-stack/blob/main/scm3.0/nov...
Does anyone know if the CVM support along with supporting Intel TDX or related technologies have been added to OpenStack already? Or if there's anyone in the community planning for adding these in the future?
Thanks and Best Regards, Ildikó
On Tue, Feb 25, 2025 at 04:17:02PM +0900, Takashi Kajinami wrote: this:
Honestly speaking I've been struggling to gather attention about the work
basically counts for:
There was a discussion in the past nova PTG about adding support for Intel SGX, but unfortunately I've seen no progress about it.
as well. The colleagues at OSISM were doing the work to see that the SGX-patchsets were brought in shape in order to upstream them. During PTG it became clear that it would need quite a bit of re-work. Before diving into that we wanted to make sure that people (users, operators) are really interested in it: however we've failed to identify basically _any_ interest among users and operators. As such we halted this effort. cheers felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr@osb-alliance.com
On 25/02/2025 08:21, Felix Kronlage-Dammers wrote:
On Tue, Feb 25, 2025 at 04:17:02PM +0900, Takashi Kajinami wrote:
this:
Honestly speaking I've been struggling to gather attention about the work basically counts for:
There was a discussion in the past nova PTG about adding support for Intel SGX, but unfortunately I've seen no progress about it. as well. The colleagues at OSISM were doing the work to see that the SGX-patchsets were brought in shape in order to upstream them. During PTG it became clear that it would need quite a bit of re-work. Before diving into that we wanted to make sure that people (users, operators) are really interested in it: however we've failed to identify basically _any_ interest among users and operators. As such we halted this effort.
nova is also a bit hesitant to accept invasive change for this because we did have integration with openattssation/trusted compute pool in the past that was developed by intel and then because abandon ware almost imeadetly once it was upstream the inital series was done 13 years ago https://review.opendev.org/q/owner:fred-yang https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools the trusted compute filter was finally deprecated in pike and removed in queens https://github.com/openstack/nova/commit/3806ead0e09f76b8b984054875682fbc68e... the orgianl trusted compute work was never properly tested and broke shortly after it was merged because the open attention spec it was based on was made obsolete. if we add confidential computing feature going forward we need to make sure they are documented, tested and maintainable by the core team, we don't accept experimental feature in tree any more like we did when that was first done and our over all testing requirement are much higher. having an operator/user need for this also goes a long way to priorities these types of features.
cheers
felix
Hi, Thank you Felix, Takashi and Sean for weighing in and sharing invaluable information about both currently ongoing work as well as history and background on past work items and decisions. I've been seeing some uptake in demands for confidential computing related methods and features, due to a raising bar in the areas of cybersecurity, data protection, etc. The Kata Containers and Confidential Containers projects are looking into integration points with platforms such as OpenStack, to deliver related functionality to more users. I passed along the information y'all shared and will keep encouraging the communities to reach out with any questions and to collaborate on next steps as they get ready to take them. Thanks and Best Regards, Ildikó
On Feb 25, 2025, at 04:29, Sean Mooney <smooney@redhat.com> wrote:
On 25/02/2025 08:21, Felix Kronlage-Dammers wrote:
On Tue, Feb 25, 2025 at 04:17:02PM +0900, Takashi Kajinami wrote:
this:
Honestly speaking I've been struggling to gather attention about the work basically counts for:
There was a discussion in the past nova PTG about adding support for Intel SGX, but unfortunately I've seen no progress about it. as well. The colleagues at OSISM were doing the work to see that the SGX-patchsets were brought in shape in order to upstream them. During PTG it became clear that it would need quite a bit of re-work. Before diving into that we wanted to make sure that people (users, operators) are really interested in it: however we've failed to identify basically _any_ interest among users and operators. As such we halted this effort.
nova is also a bit hesitant to accept invasive change for this because we did have integration with openattssation/trusted compute pool
in the past that was developed by intel and then because abandon ware almost imeadetly once it was upstream
the inital series was done 13 years ago https://review.opendev.org/q/owner:fred-yang
https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools
the trusted compute filter was finally deprecated in pike and removed in queens
https://github.com/openstack/nova/commit/3806ead0e09f76b8b984054875682fbc68e...
the orgianl trusted compute work was never properly tested and broke shortly after it was merged because the open attention spec it was based on was made obsolete.
if we add confidential computing feature going forward we need to make sure they are documented, tested and maintainable by the core team, we don't accept experimental feature in tree any more like we did when that was first done and our over all testing requirement are much higher. having an operator/user need for this also goes a long way to priorities these types of features.
cheers
felix
participants (4)
-
Felix Kronlage-Dammers
-
Ildiko Vancsa
-
Sean Mooney
-
Takashi Kajinami