mirror of https://github.com/acidanthera/audk.git
fda8f631ed
According to the TCG Platform Reset Attack Mitigation Specification (May 15, 2008): > 5 Interface for UEFI > 5.1 UEFI Variable > 5.1.1 The MemoryOverwriteRequestControl > > Start of informative comment: > > [...] The OS loader should not create the variable. Rather, the firmware > is required to create it and must support the semantics described here. > > End of informative comment. However, some OS kernels create the MOR variable even if the platform firmware does not support it (see one Bugzilla reference below). This OS issue breaks the logic added in the last patch. Strengthen the MOR check by searching for the TCG or TCG2 protocols, as edk2's implementation of MOR depends on (one of) those protocols. The protocols are defined under MdePkg, thus there's no inter-package dependency issue. In addition, calling UEFI services in MorLockInitAtEndOfDxe() is safe, due to the following order of events / actions: - platform BDS signals the EndOfDxe event group, - the SMM core installs the SmmEndOfDxe protocol, - MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services, - some time later, platform BDS installs the DxeSmmReadyToLock protocol, - SMM / SMRAM is locked down and UEFI services become unavailable to SMM drivers. Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ladi Prosek <lprosek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Ladi Prosek <lprosek@redhat.com> |
||
|---|---|---|
| .. | ||
| EmuRuntimeDxe | ||
| Pei | ||
| RuntimeDxe | ||