[Bug 2122286] Re: firmware definitions lack "amd-sev-es" feature
Lukas Märdian
2122286 at bugs.launchpad.net
Wed Oct 22 08:55:01 UTC 2025
Thank you Hector for the updates!
After plenty of discussions we agreed that we still want to go with
option (2) from comment #6, i.e. implementing a bigger scope (that is
more isolated, though, inside a new OVMF.amdsev.fd file).
This new OVMF.amdsev.fd file would enable SEV-ES support in addition to
SEV-SNP support (only when used with newer Qemu, e.g. from server-
backports).
It's the same solution we applied to Plucky+ which also covers this reduced "SEV-ES" scope.
The testplan was updated accordingly to only test for SEV-ES on Noble, as SEV-SNP is not available by default on Noble.
** Changed in: edk2 (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to edk2 in Ubuntu.
https://bugs.launchpad.net/bugs/2122286
Title:
firmware definitions lack "amd-sev-es" feature
Status in edk2 package in Ubuntu:
Fix Released
Status in edk2 source package in Noble:
New
Bug description:
[ Impact ]
* On the Noble release, the launch of AMD-SEV SNP QEMU VM fails due to
the absence of OVMF amdsev file in the OVMF package
* none of the firmware definition files contain "amd-sev-es" feature
so libvirt fails to detect the appropriate firmware for AMD SEV ES VM.
* Noble OVMF package requires the integration of the AMD SEV firmware
file "OVMF.amdsev.fd", to enable support for SEV-secured VM remote
attestation and secret injection.
* This upload fixes this by adopting the d/rules file according to the
build instructions from bug #2106771
[ Test Plan ]
* Use hardware that supports AMD SEV-ES features, e.g.: AMD EPYC 9654
96-Core Processor. This can be verified by following checks:
1) looking into the dmesg output:
Jul 17 09:22:30 hoodin kernel: ccp 0000:01:00.5: sev enabled
Jul 17 09:22:36 hoodin kernel: ccp 0000:01:00.5: SEV API:1.55 build:40
Jul 17 09:22:36 hoodin kernel: kvm_amd: SEV enabled (ASIDs 10 - 1006)
Jul 17 09:22:36 hoodin kernel: kvm_amd: SEV-ES enabled (ASIDs 1 - 9)
2) checking that /proc/cpuinfo contains sev_es feature flag
3) /sys/module/kvm_amd/parameters/sev_es is set to "Y"
* Launch a QEMU 24.04 guest [1], using:
NB: You would need to modify the user root password to be able to login to the console in order to do some checks:
$ sudo virt-customize -a ubuntu-24.04-server-cloudimg-amd64.img --root-password password:root
1) QEMU
sudo qemu-system-x86_64 -enable-kvm -nographic -cpu EPYC-v4 -machine
q35 -smp 6 -m 6G -machine confidential-guest-support=sev0,vmport=off
-object memory-backend-memfd,id=ram1,size=6G,share=true,prealloc=false
-machine memory-backend=ram1 -object sev-
guest,id=sev0,cbitpos=51,reduced-phys-bits=1,policy=0x5 -drive
"if=virtio,format=qcow2,file=ubuntu-24.04-server-cloudimg-amd64.img"
-bios /usr/share/ovmf/OVMF.amdsev.fd -net nic -net user
* Inside the guest, confirm AMD SEV-ES got activated by checking the
dmesg out put:
[ 0.889475] Memory Encryption Features active: AMD SEV SEV-ES
2) libvirt
NB: as of now, libvirt cannot run AMD SEV VM because it lacks apparmor access to the /dev/sev. A LP bug has been reported to fix this issue: bug #2127492
To work-around it:
- Modify the libvirt-qemu apparmor abstraction : /etc/apparmor.d/abstractions/libvirt-qemu by adding the line
/dev/sev rw,
- Restart apparmor : sudo systemctl restart apparmor
$ cat sev-es.xml
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>sev</name>
<memory unit='GiB'>16</memory>
<memoryBacking>
<locked/>
</memoryBacking>
<vcpu placement="static">32</vcpu>
<os firmware="efi">
<type arch='x86_64' machine='q35'>hvm</type>
<loader stateless='yes'/>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<vmport state='off'/>
</features>
<cpu mode='host-model' check='partial'>
<model fallback='allow'/>
</cpu>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2"/>
<source file="/tmp/ubuntu-24.04-server-cloudimg-amd64.img"/>
<target dev="vda" bus="virtio"/>
</disk>
<console type='pty'>
<target type='virtio' port='1'/>
</console>
<channel type='unix'>
<source mode='bind'/>
<target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>
</devices>
<allowReboot value='no'/>
<launchSecurity type='sev'>
<policy>0x4</policy>
</launchSecurity>
</domain>
NB: policy 0x4 means that we want to enable SEV-ES for the AMD-SEV VM
(https://github.com/qemu/qemu/blob/master/target/i386/sev.h#L37)
$ virsh define sev-es
$ virsh start sev
Without the proposed SRU, the VM cannot be run with the error message:
$ virsh define sev.xml
error: Failed to define domain from sev.xml
error: operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
With the fix:
The VM should start and:
a) AMD SEV ES should be enable in the guest:
(you can see guest boot log by using : virsh console <domain-id>)
dmesg:
[ 0.889475] Memory Encryption Features active: AMD SEV SEV-ES
b) the OVMF.amdsev.fd is used by libvirt when it invokes QEMU, this can be verified by running:
$ ps aux | grep qemu-system-x86
[ Where problems could occur ]
* we're modifying the d/rules Makefile, to create a new, independent
"OVMF.amdsev.fd" UEFI rom.
* If anything goes wrong in d/rules, the package could FTBFS
* Besides that the new 60-edk2-x86_64-amdsev.json could provide wrong
metadata which would make the new "OVMF.amdsev.fd" not be properly
autodetected. Any issues inside the "OVMF.amdsev.fd" rom itself should
be isolated to the specific AMD SEV usecase itself.
[ Other Info ]
* This was enabled in Ubuntu Plucky and above in bug #2106771, which
included support for SEV-ES & SEV-SNP (as supported by QEMU 9.1),
whereas on Noble we can only support SEV-ES (as supported by QEMU 6.0)
* How to launch a AMD SEV VM:
https://www.qemu.org/docs/master/system/i386/amd-memory-
encryption.html#launching-sev-and-sev-es
* Suggested upstream proposal for making /dev/sev accessible via
AppArmor in bug #2127492
[1] 24.04 Guest image: https://cloud-
images.ubuntu.com/releases/noble/release/ubuntu-24.04-server-cloudimg-
amd64.img
--- original bug report ---
libvirt has had the capability to select the appropriate UEFI firmware according to the features requested.
Especially it introduced the selection logic for AMD SEV-ES in 7.2.0 which depends on the amd-sev-es feature contained in the firmware capability definitions, stored in /usr/share/qemu/firmware/ .
https://github.com/libvirt/libvirt/commit/f14ca48ef42e552d97cac096968e95680b3c75b4
However none of the firmware definition files contain "amd-sev-es"
feature so libvirt fails to detect the appropriate firmware.
---
$ grep -r amd-sev /usr/share/qemu/firmware/
/usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json: "amd-sev",
/usr/share/qemu/firmware/60-edk2-x86_64.json: "amd-sev",
/usr/share/qemu/firmware/50-edk2-x86_64-secure.json: "amd-sev",
---
1)
$ lsb_release -rd
No LSB modules are available.
Description: Ubuntu 24.04 LTS
Release: 24.04
2)
---
$ apt-cache policy ovmf
ovmf:
Installed: 2024.02-2ubuntu0.4
Candidate: 2024.02-2ubuntu0.4
Version table:
*** 2024.02-2ubuntu0.4 500
500 http://il.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
100 /var/lib/dpkg/status
2024.02-2ubuntu0.3 500
500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
2024.02-2 500
500 http://il.archive.ubuntu.com/ubuntu noble/main amd64 Packages
---
3)
At least one firmware definition file with "amd-sev-es" feature exists
3)
None of firmware definition files contain "amd-sev-es" feature
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2122286/+subscriptions
More information about the foundations-bugs
mailing list