libvirt driver launching instances with memory encryption by AMD SEV-SNP¶

https://blueprints.launchpad.net/nova/+spec/amd-sev-snp-libvirt-support

This spec proposes work required in order to extend the existing libvirt driver feature to launch AMD SEV-encrypted instances, to support also using AMD SEV-SNP.

Problem description¶

Current libvirt driver supports launching instances with memory encryption by AMD’s SEV (Secure Encrypted Virtualization) technology. However the current implementation supports only AMD SEV and AMD SEV-ES.

AMD SEV-SNP is the third generation of AMD SEV technology, and provides more strict integrity protection, in addition to the existing AMD SEV-ES. One of its important features is platform attestation, which allows guest owners to verify the integrity of their guests based on the attestation reports, generated by the secure processors within CPUs and then signed with the private protected keys, sealed in these secure processors. Due to these benefits, AMD SEV-SNP is now one of the major technologies used in confidential computing use case.

However users and operators can’t use these features because of lack of support for SEV-SNP.

Use Cases¶

As a cloud administrator, in order that my users can have more confidence in the security of their running instances, I want to provide an image with the specific properties or a flavor with the specific extra specs which will allow users to boot instances to ensure that their instances run on an SEV-SNP-capable compute host with SEV-SNP encryption.
As a cloud user, in order to reduce data leakage risks further, I want to be able to boot VM instances with SEV-SNP functionality. Also I want to verify integrity of my VMs using attestation reports generated by the secure processor within AMD CPUs.

Proposed change¶

We propose extending the existing implementation to support launching instances with SEV/SEV-ES functionality.

Make the libvirt driver to detect sev_snp cpu flag from /proc/cpuinfo. The driver should ignore the SEV-ES capability if the flag is present. Also its init_host should fail if the flag is detected and there are any existing instances with SEV-ES encryption in its host, with the explicit error message to request operators to disable SEV-SNP or migrate all these instances to different nodes.

Note

The change described above is required because the recent firmware update disables SEV-ES when SEV-SNP is enabled, due to CVE-2025-48514 .
Add detection of host SEV-SNP capabilities in hypervisor, which checks the following items.
- The presence of the following XML in the response from a libvirt virConnectGetDomainCapabilities() API call indicates that both QEMU and the AMD Secure Processor (AMD-SP) support SEV functionality:
```
<domainCapabilities>
  ...
  <features>
    ...
    <sev supported='yes'/>
      ...
    </sev>
  </features>
</domainCapabilities>
```
  Also the maxESGuests field should be present and its value should be a positive (non-zero) value.
- /sys/module/kvm_amd/parameters/sev_snp should have the value Y to indicate that SEV-SNP support is enabled in BIOS (or UEFI) and also the SEV-SNP support of the kvm kernel module is enabled. This sysfs path should be readable by any user (i.e. even non-root).
- Check QEMU version and libvirt version to determine whether the available QEMU binary and libvirt binary support SEV-SNP.
Add the new HW_CPU_AMD_SEV_SNP trait to os-traits.

Make the libvirt driver update the ProviderTree object with ASIDs for SEV-SNP. Because SEV-SNP uses the specific ASIDs pool, we create a separate resource provider with the HW_CPU_AMD_SEV_SNP trait:

+------------+     +----------------------------+
| compute RP +--+--+ SEV RP                     |
+------------+  |  | trait:HW_CPU_AMD_SEV       |
                |  +------------------------+---+
                |  | MEM_ENCRYPTION_CONTEXT | N |
                |  +------------------------+---+
                |
                |  +----------------------------+
                +--+ SEV-SNP RP                 |
                   | trait:HW_CPU_AMD_SEV_SNP   |
                   +------------------------+---+
                   | MEM_ENCRYPTION_CONTEXT | N |
                   +------------------------+---+

The maxESGuests attribute exposed by libvirt will be used to determine the amount of the MEM_ENCRYPTION_CONTEXT resource in the SEV-SNP resource provider. This value reflects the CPUID field which represents the number of ASIDs available for SEV-ES or SEV-SNP.

Note

SEV-SNP uses a separate ASID pool when ciphertext hiding (which is supported since AMD EPYC 9005 and kernel 6.18) is enabled, but this feature is out of our current scope.

Extend handling of the hw:mem_encryption_model parameter in flavor extra specs, and the hw_mem_encryption_model image property, to support the new value, amd-sev-snp. Either of these is set to amd-sev-snp along with the parameter/property to enable memory encryption, it would be internally translated to resources:MEM_ENCRYPTION_CONTEXT=1 and trait:HW_CPU_AMD_SEV_SNP=required. If conflicting models are requested by the instance flavor and the instance image then the request is rejected. Also amd-sev-snp requires stateless firmware, so explicit hw_firmware_stateless=True image property setting is also required.
Change the libvirt driver to include extra XML in the guest’s domain definition when the hw:mem_encryption_model parameter in flavor extra spec or the hw_mem_encryption_model image property is present and is set to amd-sev-snp:
```
<launchSecurity type='sev-snp' authorKey='no' vcek='yes' kernelHashes='no'>
  <policy>0x00030000</policy>
</launchSecurity>
```
See the libvirt guide to find further details about the launchSecurity element.
- The policy attribute is hard-coded to the most standard value at this moment following the existing AMD SEV/SEV-ES support.
- The authorKey attribute is hard-coded to no, because support for idAuth is out of scope.
- The vcek attribute is hard-coded to yes. Restriction to VLEK is out of scope because VLEK is currently available for the limited cloud providers.
- The kernelHashes attribute is set to yes when the instance uses Direct Kernel Boot. This enables the measured boot feature in OVMF and allows guest owners to get digest of bootchain components (OVMF, initramfs, kernel and kernel args) as part of attestation reports. Usage of Direct Kernel Boot is detected according to the kernel_id property of the image.
- The cbitpos attribute and the reducedPhysBits attribute are not explicitly defined because these are optional since libvirt v6.9.0 . These may be removed from the existing SEV/SEV-ES implementation.
Note

SEV-SNP supports a few more fields such as idBlock, idAuth and hostData. These are expected to be provided by guest owner, thus should be defined per-instance. However due to lack of per-instance properties in nova, these options are out of the current scope.

Note

The locked attribute doesn’t have to be set for SEV-SNP.

Alternatives¶

Reuse the existing SEV-ES resource provider to represent ASID slots for SEV-SNP. This was the old plan we had when SEV-ES and SEV-SNP could be enable at the same time. However, as explained in the above section, recent firmware versions no longer support enabling both, so we have to use SEV-ES resource provider for only SEV-SNP which is confusing.

Data model impact¶

None

REST API impact¶

None

Security impact¶

None

Notifications impact¶

None

Other end user impact¶

The end user will harness SEV-SNP through the existing mechanisms of resources in flavor extra specs and image properties.

Also the limitations of AMD SEV-encrypted guest are applied when SEV-SNP is used. For example live migration and suspend are both unsupported for SEV-SNP encrypted instances.

Performance Impact¶

No performance impact on nova is anticipated.

Performance impact for the other parts are same as the existing SEV support feature.

Other deployer impact¶

In order for users to be able to use SEV-SNP, the operator will need to perform the following steps:

Deploy SEV-SNP-capable hardware as nova compute hosts.
- AMD EPYC 7003 (Milan) or later
Set the minimum ASID for SEV (non-ES) guests in BIOS (or UEFI) to a value greater than 0. This allows everything below the minimum to be used for SEV-ES and SEV-SNP guests. This setting is the common requirement in both SEV-ES and SEV-SNP.
Enable SEV-SNP in BIOS (or UEFI).
Ensure that they have an appropriately configured software stack, so that the various layers are all SEV-SNP ready:
- kernel >= 6.11
- QEMU >= 9.1.0
- libvirt >= 10.5.0
- ovmf >= edk2-stable202202
These requirements can be met by using Ubuntu 25.04 or later .

A cloud administrator will need to define SEV-SNP-enabled flavors as described above, unless it is sufficient for users to define SEV-SNP-enabled images.

Also, the specific QEMU firmware descriptor file, which tells libvirt to use rom type firmware is required. The file should contain the following content:

{
  "description": "UEFI firmware for x86_64, with SEV-SNP support",
  "interface-types": [
    "uefi"
  ],
  "mapping": {
    "device": "memory",
    "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd"
  },
  "targets": [
    {
      "architecture": "x86_64",
      "machines": [
        "pc-q35-*"
      ]
    }
  ],
  "features": [
    "amd-sev-snp"
  ],
  "tags": [
  ]
}

This isn’t yet available in the files installed by QEMU packages in distros and might need to be created additionally. See the libvirt mailing list post for reference.

Developer impact¶

None

Upgrade impact¶

If any instances with SEV-ES encryption are already created in the compute host, nova-compute fails to start due to the new validation. Operators should migrate the existing instances with SEV-ES encryption before SEV-SNP is enabled.

Implementation¶

Assignee(s)¶

Primary assignee:: kajinamit (irc: tkajinam)
Other contributors:: nhirokinet (irc: nhirokinet)

Work Items¶

Add startup validation to fail when the sev_snp flag is available in host CPU flags, but there is any existing instances with SEV-ES encryption in that host.
Add the new HW_CPU_AMD_SEV_SNP trait for os-traits
Add detection of host SEV-SNP capabilities as detailed above so that the new SEV-SNP RP with the HW_CPU_AMD_SEV_SNP trait is created.
Add mem_encryption_model property to ImageMeta object
Update scheduler util to request MEM_ENCRYPTION_CONTEXT resource and HW_CPU_AMD_SEV_SNP trait when the mem_encryption_model property or the equivalent flavor extra spec is set to amd-sev-snp
Update libvirt driver to generate the xml element to use SEV-SNP.
Update image property schema in glance to validate the new mem_encryption_model property.
Update documentations.

Unit tests and functional tests should be added according to new logic.

Future work¶

None

Dependencies¶

Special hardware which supports SEV-SNP for development, testing, and CI.
Recent versions of the hypervisor software stack which all support SEV-SNP, as detailed in Other deployer impact above.

Testing¶

The fakelibvirt test driver will need adaptation to emulate SEV-SNP-capable hardware.

Corresponding unit/functional tests will need to be extended or added to cover:

detection of SEV-SNP-capable hardware and software, e.g. perhaps as an extension of nova.tests.functional.libvirt.test_report_cpu_traits.LibvirtReportTraitsTests
the use of a trait to include extra SEV-specific libvirt domain XML configuration, e.g. within nova.tests.unit.virt.libvirt.test_config
Add a simple test scenario to whitebox-tempest-plugin to launch instances with SEV-SNP encryption. Although this can’t be run in CI due to lack of the required hardware, but helps other developers to verify the feature.

Documentation Impact¶

Update the entry in the Feature Support Matrix, to explain now AMD SEV-SNP is supported in addition to AMD SEV.
Update the existing AMD SEV guide to include information about SEV-SNP.

Other non-nova documentation should be updated too:

The documentation for os-traits should be extended where appropriate.

References¶

History¶

Revisions¶
Release Name	Description
2026.2 Hibiscus	Introduced

libvirt driver launching instances with memory encryption by AMD SEV-SNP

libvirt driver launching instances with memory encryption by AMD SEV-SNP¶

Problem description¶

Use Cases¶

Proposed change¶

Alternatives¶

Data model impact¶

REST API impact¶

Security impact¶

Notifications impact¶

Other end user impact¶

Performance Impact¶

Other deployer impact¶

Developer impact¶

Upgrade impact¶

Implementation¶

Assignee(s)¶

Work Items¶

Future work¶

Dependencies¶

Testing¶

Documentation Impact¶

References¶

History¶

Nova Specs

Page Contents