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.
*** Bug 1794216 has been marked as a duplicate of this bug. ***
Created attachment 1788699 [details] Test results with rhel 8.4 guest image and puddle RHOS-16.2-RHEL-8-20210525.n.0
According to our records, this should be resolved by openstack-nova-20.6.2-2.20210607104828.el8ost.4. This build is available now.