2040646 – The -bios option does not initialize AMD SEV OVMF firmware builds

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2040646 - The -bios option does not initialize AMD SEV OVMF firmware builds

Summary: The -bios option does not initialize AMD SEV OVMF firmware builds

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	qemu-kvm
Sub Component:
Version:	8.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Daniel Berrangé
QA Contact:	zixchen
Docs Contact:
URL:
Whiteboard:
Depends On:	1985468 2040638 2040644 2085086
Blocks:
TreeView+	depends on / blocked

Reported:	2022-01-14 11:03 UTC by Daniel Berrangé
Modified:	2023-07-27 02:41 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2023-06-26 21:13:46 UTC
Type:	Epic
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHELPLAN-108171	0	None	None	None	2022-01-14 11:08:01 UTC

Description Daniel Berrangé 2022-01-14 11:03:21 UTC

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:

Comment 1 John Ferlan 2022-10-17 20:30:27 UTC

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)

Comment 2 John Ferlan 2023-05-22 13:12:36 UTC

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.

Comment 3 Daniel Berrangé 2023-06-06 10:29:47 UTC

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.

Comment 5 zixchen 2023-06-08 09:41:35 UTC

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

Comment 6 zixchen 2023-06-08 10:00:31 UTC

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": [

    ]
}

Comment 8 John Ferlan 2023-06-26 21:13:46 UTC

Closing using currentrelease indicating all changes are in some current RHEL release.

Comment 9 zixchen 2023-06-27 05:17:34 UTC

(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": [
> 
>     ]
> }

Comment 10 Gerd Hoffmann 2023-06-27 06:10:45 UTC

(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.

Note You need to log in before you can comment on or make changes to this bug.