Description of problem: To quote what I wrote in https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02957.html The AMD SEV build of EDK2 only emits a single file, intended to be mapped readonly. There is explicitly no separate writable VARS store for persisting non-volatile firmware variables. This can be used with QEMU's traditional pflash configuration mechanism by only populating pflash0, leaving pflash1 unconfigured. Conceptually, however, it is odd to be using pflash at all when we have no intention of supporting any writable variables. The -bios option should be sufficient for any firmware that is exclusively readonly code. A second issue is that the firmware descriptor schema does not allow for describing a firmware that uses pflash, without any associated non-volatile storage. In docs/interop/firmware.json 'struct' : 'FirmwareMappingFlash', 'data' : { 'executable' : 'FirmwareFlashFile', 'nvram-template' : 'FirmwareFlashFile' } } Notice that nvram-template is mandatory, and when consuming these files libvirt will thus complain if the nvram-template field is missing. We could in theory make nvram-template optional in the schema and then update libvirt to take account of it, but this feels dubious when we have a perfectly good way of describing a firmware without NVRAM, using 'FirmwareMappingMemory' which is intended to be used with QEMU's -bios option. A third issue is in libvirt, where again the code handling the configuration of pflash supports two scenarios - A single pflash image, which is writable - A pair of pflash images, one writable one readonly There is no support for a single read-only pflash image in libvirt today. This all points towards the fact that we should be using -bios to load the AMD SEV firmware build of EDK. The only thing preventing us doing that is that QEMU does not initialize the SEV firmware when using -bios. This needs fixing hence this bug. Version-Release number of selected component (if applicable): 6.2.0-2 How reproducible: Always Steps to Reproduce: 1. Configure and boot a guest with AMD SEV, including the <dhCert> and <session> blob data, using <loader type="rom">/path/to/Amd/Sev/Build/of/OVMF</loader>. 2. Query the AMD SEV measurement for the guest 3. Compare to the expected measurement I'm afraid the steps above are a little difficult to validate in RHEL at time of filing this bug because: - We don't have any tool to create the <dhCert> and <session> data yet (pending bug 2033654) - We don't build the AMD SEV variant of OVMF yet (pending bug 1985468) - We don't have any tool to calculate the expected SEV measurement, nor documentation on how to do it yourself (pending bugs 2040638 / 2040644) Actual results: The measurements don't match Expected results: THe measurements match Additional info:
Changing dependent bug 2033654 (a sevctl-3.0 RHEL9 resolved bz) for bug 2085086 (the sevctl-3.0 RHEL8 rebase bz which has the same support)
Dan given that the bugs referenced in the problem statement and depends on have been resolved in some way and that SEV/SEV-ES is not our target, can we close this one? Not clear if there's remaining work - if so, we probably should create new bugs and use epics to track instead.
Yes, I think we can close this. All the stuff we need wrt to SEV/SEV-ES was implemented and tested via other BZs already I believe.
Test "-bios /usr/share/edk2/ovmf/OVMF.amdsev.fd" with sev-es direct kernel boot, measured boot with <dhCert> and <session> blob, all pass, no issue found. Version: kernel-5.14.0-322.el9.x86_64 edk2-ovmf-20230301gitf80f052277c8-5.el9.noarch qemu-kvm-8.0.0-4.el9.x86_64 libvirt-9.3.0-2.el9.x86_64 libvirt-client-qemu-9.3.0-2.el9.x86_64 Steps: 1. Direct kernel boot: ... -object '{"qom-type":"sev-guest","id":"lsec0","cbitpos":51,"reduced-phys-bits":1,"policy":7,"kernel-hashes":true}' \ -bios /usr/share/edk2/ovmf/OVMF.amdsev.fd \ -machine q35,memory-backend=mem-machine_mem,confidential-guest-support=lsec0 \ ... 2. Measured boot with <dhCert> and <session> blob xml: ... <os> <type arch='x86_64' machine='pc-q35-rhel9.2.0'>hvm</type> <loader readonly='yes' type='rom'>/usr/share/edk2/ovmf/OVMF.amdsev.fd</loader> <boot dev='hd'/> </os> <launchSecurity type='sev'> <policy>0x0007</policy> <dhCert>AQAAAAAAAAADEAAAAwAAAAIAAACqKGFERtH6rI9dz9F6+HNqg9vItINZS6FczVqU9EbtKmiZwvJcQswztq47jyzM2ZMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxVfCnk++J/kDaQsyhSuy6nWgm3N7wlESWm4zfowVQIZ3FTDXcXZ7TRq2KtVYfmOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</dhCert> <session>Y8CA3CwRQZmS3pff69VhoJ+bdPZZA14Vyn8wH8nGYzigCkV6sg5OKhpAidDDk0n+wAT8jUwvoafZmpvabe4xBXRMqdMJEKk465WFQHt7UrHoJeF/dZ0EZOM2HYOAlo8qksNO/y9Mxu8WKNCeL/2gOtk2N9TRdNPYet5Nigis4hI=</session> </launchSecurity> ... # virt-qemu-sev-validate --tik sev_es_dhcert_tik.bin --tek sev_es_dhcert_tek.bin --domain rhel9_sev --insecure OK: Looks good to me
Hi Daniel, I have a question about adding -bios support to the sev-es test plan. Libvirt has a loader option stateless=yes, when using uefi boot with sev-es, /usr/share/edk2/ovmf/OVMF.amdsev.fd will be automatically used. So -bios(loader type=rom) and plflash with stateless=yes, they look like two solutions on sev-es firmware file OVMF.amdsev.fd. As the following json file, libvirt will use pflash with stateless=yes, does this bug will change the current strategy and the following json file? Should QE test the 2 solutions with the same priority? # cat /usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json { "description": "OVMF with SEV-ES support", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "amd-sev", "amd-sev-es", "amd-sev-snp", "verbose-dynamic" ], "tags": [ ] }
Closing using currentrelease indicating all changes are in some current RHEL release.
(In reply to zixchen from comment #6) > Hi Daniel, I have a question about adding -bios support to the sev-es test > plan. Libvirt has a loader option stateless=yes, when using uefi boot with > sev-es, /usr/share/edk2/ovmf/OVMF.amdsev.fd will be automatically used. So > -bios(loader type=rom) and plflash with stateless=yes, they look like two > solutions on sev-es firmware file OVMF.amdsev.fd. > As the following json file, libvirt will use pflash with stateless=yes, does > this bug will change the current strategy and the following json file? > Should QE test the 2 solutions with the same priority? Hi Gerd, do you have any ideas about the above two questions? > > # cat /usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json > { > "description": "OVMF with SEV-ES support", > "interface-types": [ > "uefi" > ], > "mapping": { > "device": "flash", > "mode": "stateless", > "executable": { > "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", > "format": "raw" > } > }, > "targets": [ > { > "architecture": "x86_64", > "machines": [ > "pc-q35-*" > ] > } > ], > "features": [ > "amd-sev", > "amd-sev-es", > "amd-sev-snp", > "verbose-dynamic" > ], > "tags": [ > > ] > }
(In reply to zixchen from comment #9) > (In reply to zixchen from comment #6) > > Hi Daniel, I have a question about adding -bios support to the sev-es test > > plan. Libvirt has a loader option stateless=yes, when using uefi boot with > > sev-es, /usr/share/edk2/ovmf/OVMF.amdsev.fd will be automatically used. So > > -bios(loader type=rom) and plflash with stateless=yes, they look like two > > solutions on sev-es firmware file OVMF.amdsev.fd. > > As the following json file, libvirt will use pflash with stateless=yes, does > > this bug will change the current strategy and the following json file? > > Should QE test the 2 solutions with the same priority? > > Hi Gerd, do you have any ideas about the above two questions? Both should work fine. pflash is more important b/c this is what libvirt uses. -bios testing can be low priority.