diff options
author | Tom Lendacky <thomas.lendacky@amd.com> | 2020-08-12 15:21:42 -0500 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2020-08-17 02:46:39 +0000 |
commit | 437eb3f7a8db7681afe0e6064d3a8edb12abb766 (patch) | |
tree | 0833bdf4c966f3ed71cae5ff59bb0859fefef72f /UefiCpuPkg | |
parent | e2db781f0ce4d49d89f8993655d653c372e8ed2a (diff) | |
download | edk2-437eb3f7a8db7681afe0e6064d3a8edb12abb766.tar.gz edk2-437eb3f7a8db7681afe0e6064d3a8edb12abb766.tar.bz2 edk2-437eb3f7a8db7681afe0e6064d3a8edb12abb766.zip |
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check may result in an infinite nested page fault
because of the attempted write. Since the instruction cannot be emulated
when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
nested page faults.
When SEV-ES is enabled, exit the flash detection early and assume that
the FD behaves as Flash. This will result in QemuFlashWrite() being called
to store EFI variables, which will also result in an infinite nested page
fault when the write is performed. In this case, update QemuFlashWrite()
to use the VMGEXIT MMIO write support to have the hypervisor perform the
write without having to emulate the instruction.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Diffstat (limited to 'UefiCpuPkg')
0 files changed, 0 insertions, 0 deletions