audk/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

95 lines
2.5 KiB
C
Raw Normal View History

/** @file
OVMF support for QEMU system firmware flash device: functions specific to the
runtime DXE driver build.
Copyright (C) 2015, Red Hat, Inc.
Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include <Library/UefiRuntimeLib.h>
#include <Library/MemEncryptSevLib.h>
#include <Library/CcExitLib.h>
#include <Register/Amd/Msr.h>
#include "QemuFlash.h"
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183 Under SEV-ES, a write to the flash device is done using a direct VMGEXIT to perform an MMIO write. The address provided to the MMIO write must be the physical address of the MMIO write destitnation. During boot, OVMF runs with an identity mapped pagetable structure so that VA == PA and the VMGEXIT MMIO write destination is just the virtual address of the flash area address being written. However, when the UEFI SetVirtualAddressMap() API is invoked, an identity mapped pagetable structure may not be in place and using the virtual address for the flash area address is no longer valid. This results in writes to the flash not being performed successfully. This can be seen by attempting to change the boot order under Linux. The update will appear to be performed, based on the output of the command. But rebooting the guest will show that the new boot order has not been set. To remedy this, save the value of the flash base physical address before converting the address as part of SetVirtualAddressMap(). The physical address can then be calculated by obtaining the offset of the MMIO target virtual address relative to the flash base virtual address and adding that to the original flash base physical address. The resulting value produces a successful MMIO write during runtime services. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com> [lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo fix, in both the commit message and the code comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-01-23 14:57:44 +01:00
STATIC EFI_PHYSICAL_ADDRESS mSevEsFlashPhysBase;
VOID
QemuFlashConvertPointers (
VOID
)
{
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183 Under SEV-ES, a write to the flash device is done using a direct VMGEXIT to perform an MMIO write. The address provided to the MMIO write must be the physical address of the MMIO write destitnation. During boot, OVMF runs with an identity mapped pagetable structure so that VA == PA and the VMGEXIT MMIO write destination is just the virtual address of the flash area address being written. However, when the UEFI SetVirtualAddressMap() API is invoked, an identity mapped pagetable structure may not be in place and using the virtual address for the flash area address is no longer valid. This results in writes to the flash not being performed successfully. This can be seen by attempting to change the boot order under Linux. The update will appear to be performed, based on the output of the command. But rebooting the guest will show that the new boot order has not been set. To remedy this, save the value of the flash base physical address before converting the address as part of SetVirtualAddressMap(). The physical address can then be calculated by obtaining the offset of the MMIO target virtual address relative to the flash base virtual address and adding that to the original flash base physical address. The resulting value produces a successful MMIO write during runtime services. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com> [lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo fix, in both the commit message and the code comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-01-23 14:57:44 +01:00
if (MemEncryptSevEsIsEnabled ()) {
mSevEsFlashPhysBase = (UINTN)mFlashBase;
}
EfiConvertPointer (0x0, (VOID **)&mFlashBase);
}
VOID
QemuFlashBeforeProbe (
IN EFI_PHYSICAL_ADDRESS BaseAddress,
IN UINTN FdBlockSize,
IN UINTN FdBlockCount
)
{
//
// Do nothing
//
}
/**
Write to QEMU Flash
@param[in] Ptr Pointer to the location to write.
@param[in] Value The value to write.
**/
VOID
QemuFlashPtrWrite (
IN volatile UINT8 *Ptr,
IN UINT8 Value
)
{
if (MemEncryptSevEsIsEnabled ()) {
MSR_SEV_ES_GHCB_REGISTER Msr;
GHCB *Ghcb;
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183 Under SEV-ES, a write to the flash device is done using a direct VMGEXIT to perform an MMIO write. The address provided to the MMIO write must be the physical address of the MMIO write destitnation. During boot, OVMF runs with an identity mapped pagetable structure so that VA == PA and the VMGEXIT MMIO write destination is just the virtual address of the flash area address being written. However, when the UEFI SetVirtualAddressMap() API is invoked, an identity mapped pagetable structure may not be in place and using the virtual address for the flash area address is no longer valid. This results in writes to the flash not being performed successfully. This can be seen by attempting to change the boot order under Linux. The update will appear to be performed, based on the output of the command. But rebooting the guest will show that the new boot order has not been set. To remedy this, save the value of the flash base physical address before converting the address as part of SetVirtualAddressMap(). The physical address can then be calculated by obtaining the offset of the MMIO target virtual address relative to the flash base virtual address and adding that to the original flash base physical address. The resulting value produces a successful MMIO write during runtime services. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com> [lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo fix, in both the commit message and the code comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-01-23 14:57:44 +01:00
EFI_PHYSICAL_ADDRESS PhysAddr;
UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCB BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
2020-11-06 18:53:12 +01:00
BOOLEAN InterruptState;
Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
Ghcb = Msr.Ghcb;
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183 Under SEV-ES, a write to the flash device is done using a direct VMGEXIT to perform an MMIO write. The address provided to the MMIO write must be the physical address of the MMIO write destitnation. During boot, OVMF runs with an identity mapped pagetable structure so that VA == PA and the VMGEXIT MMIO write destination is just the virtual address of the flash area address being written. However, when the UEFI SetVirtualAddressMap() API is invoked, an identity mapped pagetable structure may not be in place and using the virtual address for the flash area address is no longer valid. This results in writes to the flash not being performed successfully. This can be seen by attempting to change the boot order under Linux. The update will appear to be performed, based on the output of the command. But rebooting the guest will show that the new boot order has not been set. To remedy this, save the value of the flash base physical address before converting the address as part of SetVirtualAddressMap(). The physical address can then be calculated by obtaining the offset of the MMIO target virtual address relative to the flash base virtual address and adding that to the original flash base physical address. The resulting value produces a successful MMIO write during runtime services. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com> [lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo fix, in both the commit message and the code comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-01-23 14:57:44 +01:00
//
// The MMIO write needs to be to the physical address of the flash pointer.
// Since this service is available as part of the EFI runtime services,
// account for a non-identity mapped VA after SetVirtualAddressMap().
//
if (mSevEsFlashPhysBase == 0) {
PhysAddr = (UINTN)Ptr;
} else {
PhysAddr = mSevEsFlashPhysBase + (Ptr - mFlashBase);
}
//
// Writing to flash is emulated by the hypervisor through the use of write
// protection. This won't work for an SEV-ES guest because the write won't
// be recognized as a true MMIO write, which would result in the required
// #VC exception. Instead, use the VMGEXIT MMIO write support directly
// to perform the update.
//
CcExitVmgInit (Ghcb, &InterruptState);
Ghcb->SharedBuffer[0] = Value;
Ghcb->SaveArea.SwScratch = (UINT64)(UINTN)Ghcb->SharedBuffer;
CcExitVmgSetOffsetValid (Ghcb, GhcbSwScratch);
CcExitVmgExit (Ghcb, SVM_EXIT_MMIO_WRITE, PhysAddr, 1);
CcExitVmgDone (Ghcb, InterruptState);
} else {
*Ptr = Value;
}
}