Forwarding-porting and retesting of upstream intel patchset for SGX and OpenStack

[fkr]

The patchset from Intel (https://github.com/intel/secured-cloud-management-stack/) for bringing SGX needs to forward-porting and retesting. This story is about making sure stories that cover:

• forward-porting
• re-testing and
• upstreaming

of the patchset exist.
The stories should be small enough so that each can be finished in one sprint.

Definition of Done:

• Tracking of SGX patch migration osism/issues#750
• User Stories that are small enough to be finished within one sprint have been written
• User Stories are linked in the epic of confidential computing (Confidential Computing - Secure all the enclaves #39)

[berendt]

1st step:

• nova
• python-novaclient
• python-openstackclient

2nd step:

• ironic
• kolla-ansible
• skyline

[fkr]

The unit tests are running successfully now, however launching sgx-enabled workloads is not possible, neither via horizon nor via api.

[fkr]

I will get in touch with @mleberec in order to establish contacts between OSISM and the intel engineers.

[mleberec]

@fkr - thanks. @berendt - give me a ping to follow up.

[berendt]

Prepared patch sets & first documentation is available in the https://github.com/osism/secured-cloud-management-stack repository.

[gndrmnn]

• The forward porting of the nova patches to the latest commit required a lot of work. See initial commit of the above repo. All unit tests should pass, if the patches are applied to 167e3380c946ffb07622a8c8079fa1b22b8c5543
• To get QEMU to canonically spawn SGX instances we need: Kernel 5.13+, QEMU 7+, libvirt 8.10+ therefore the host system was upgraded to Ubuntu 23.10.
• There is an unsolved problem with the placement API, which automatically purges the CUSTOM_SGX_EPC_MB inventory class every few minutes. For development purposes we solved this by being fast with creating the class and spawning the instances. This needs a proper fix in the placement API long term.
• We had problems spawning SGX instances from nova, because of cryptic permission errors. It turns out it was an AppArmor problem and the Intel documentation was not up to date. Solved by disabling the security_driver in libvirt for the time being.
• With the changes to the patch set applied in Getting nova to spawn a SGX instance osism/secured-cloud-management-stack#1 we got to spawn an SGX instance using nova successfully.

[fkr]

We should probably see about getting in touch with nova people before vPTG so that we can discuss upstreaming the effort during the d-cycle.

[fkr]

Legal requirements have been solved, the Intel Repository now carries a valid LICENSE file.

[gndrmnn]

Nova patch set was rebased on an upstream commit from 2024

New base commit is 6531ed6310c4c11ee807e10d1a0fa91658c3afea

[gndrmnn]

• Updated documentation/commit messages to reflect changes
• Fixed unit tests to use the newly introduced method to spawn nova instances
• Fixed race condition for custom SGX resource
• Updated guide to install SGX on a devstack https://github.com/osism/secured-cloud-management-stack/blob/main/doc/IndevDoc.md
• Rebased to current master. Base commit is now 3209f6551652cff7bef0b9d9719ab940dd05a0f8

[fkr]

thanks @gndrmnn for keeping this updated.