Bug 1794216

Summary: [RFE][Test Only] AMD SEV-encrypted instances (non-move operations)
Product: Red Hat OpenStack Reporter: Erwan Gallen <egallen>
Component: openstack-novaAssignee: smooney
Status: CLOSED DUPLICATE QA Contact: Archit Modi <amodi>
Severity: medium Docs Contact:
Priority: high    
Version: 16.2 (Train)CC: amodi, dasmith, eglynn, igallagh, jhakimra, kchamart, lyarwood, nwolf, sbauza, scohen, sgordon, spower, stephenfin, vromanso
Target Milestone: AlphaKeywords: FutureFeature, TechPreview, TestOnly, Triaged
Target Release: 16.2 (Train on RHEL 8.4)   
Hardware: Unspecified   
OS: Linux   
Whiteboard: docs-accepted
Fixed In Version: openstack-nova-20.4.2-2.20201114104928 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-01 11:47:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1883134, 1954529, 1959360    
Bug Blocks: 1832834, 1833442, 1913699    

Description Erwan Gallen 2020-01-22 23:07:09 UTC
Description of problem:
While data is typically encrypted today when stored on disk, it is stored in DRAM in the clear. This can leave the data vulnerable to snooping by unauthorized administrators or software, or by hardware probing. New non-volatile memory technology (NVDIMM) exacerbates this problem since an NVDIMM chip can be physically removed from a system with the data intact, similar to a hard drive. Without encryption any stored information such as sensitive data, passwords, or secret keys can be easily compromised.

AMD’s SEV offers a VM protection technology which transparently encrypts the memory of each VM with a unique key. It can also calculate a signature of the memory contents, which can be sent to the VM’s owner as an attestation that the memory was encrypted correctly by the firmware. SEV is particularly applicable to cloud computing since it can reduce the amount of trust VMs need to place in the hypervisor and administrator of their host system.

Use Cases
As a cloud administrator, in order that my users can have greater confidence in the security of their running instances, I want to provide a flavor containing an SEV-specific extra spec resource requirement which will allow users booting instances with that flavor to ensure that their instances run on an SEV-capable compute host with SEV encryption enabled.

As a cloud user, in order to not have to trust my cloud operator with my secrets, I want to be able to boot VM instances with SEV functionality enabled.

Comment 6 Kashyap Chamarthy 2020-04-20 11:32:43 UTC
Important note to QE:

I was just highlighted of a bug involving SEV and multiple NUMA nodes
(refer to Dave Gilbert's comment #25 here):

    https://bugzilla.redhat.com/show_bug.cgi?id=1814502 -- AMD/SEV: 
    Guest fails booting with hugepages : cannot bind memory to host NUMA
    nodes: Input/output error

The above bug does not trigger for a *single* NUMA node.  But it is
likely to trigger with multiple nodes.

So it's recommended that Nova QE make sure to test SEV with Nova's
various features related to NUMA (multiple nodes), CPU pinning, and huge
pages.

Comment 18 Lee Yarwood 2021-06-01 11:47:23 UTC

*** This bug has been marked as a duplicate of bug 1959360 ***

Comment 19 Lee Yarwood 2021-06-01 11:48:04 UTC

*** This bug has been marked as a duplicate of bug 1833442 ***