summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/SmmAccess/SmmAccessPei.c
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2019-09-23 11:41:41 +0200
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2020-02-05 12:59:32 +0000
commit9108fc17b09cf89a6dad0dcad3e15fb884ccf707 (patch)
tree646aade93f26e87051783352d87c307769bb0387 /OvmfPkg/SmmAccess/SmmAccessPei.c
parent300aae1180909b9141225d6a67e100fbfacc758f (diff)
downloadedk2-9108fc17b09cf89a6dad0dcad3e15fb884ccf707.tar.gz
edk2-9108fc17b09cf89a6dad0dcad3e15fb884ccf707.tar.bz2
edk2-9108fc17b09cf89a6dad0dcad3e15fb884ccf707.zip
OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE
During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by platform BDS, the SMM IPL locks SMRAM (TSEG) through EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c". During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See S3ResumeExecuteBootScript() in "UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c". Those are precisely the places where the SMRAM at the default SMBASE should be locked too. Add such an action to SmramAccessLock(). Notes: - The SMRAM at the default SMBASE doesn't support the "closed and unlocked" state (and so it can't be closed without locking it, and it cannot be opened after closing it). - The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM in question is not "general purpose"; it's only QEMU's solution to protect the initial SMI handler from the OS, when a VCPU is hot-plugged. Consequently, the state of the SMRAM at the default SMBASE is not reflected in the "OpenState" / "LockState" fields of the protocol and PPI. - An alternative to extending SmramAccessLock() would be to register an EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in SmmAccessPei (for locking at S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Diffstat (limited to 'OvmfPkg/SmmAccess/SmmAccessPei.c')
-rw-r--r--OvmfPkg/SmmAccess/SmmAccessPei.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c b/OvmfPkg/SmmAccess/SmmAccessPei.c
index d67850651c..c8bbc17e90 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.c
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
@@ -373,6 +373,12 @@ SmmAccessPeiEntryPoint (
sizeof SmramMap[DescIdxSmmS3ResumeState]);
//
+ // SmramAccessLock() depends on "mQ35SmramAtDefaultSmbase"; init the latter
+ // just before exposing the former via PEI_SMM_ACCESS_PPI.Lock().
+ //
+ InitQ35SmramAtDefaultSmbase ();
+
+ //
// We're done. The next step should succeed, but even if it fails, we can't
// roll back the above BuildGuidHob() allocation, because PEI doesn't support
// releasing memory.