In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM drivers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Mark EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS as deprecated.
1. Make SetVariable/QueryVariableInfo return EFI_UNSUPPORTED with this
attribute
2. No change to GetVariable/GetNextVariableName
Also update several function descriptors accordingly
Cc: Long Qin <qin.long@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Long Qin <qin.long@intel.com>
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>
The "MemoryOverwriteRequestControl" (a.k.a. MOR) variable comes from the
"TCG Platform Reset Attack Mitigation Specification":
https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf
The "MemoryOverwriteRequestControlLock" variable (a.k.a. MORL) is a
Microsoft extension, called "Secure MOR implementation":
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-requirements
Currently the VariableSmm driver creates MORL without regard to MOR. This
can lead to a situation where a platform does not support MOR from the
prerequisite spec (because it does not include the
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf" driver), but appears
to support MORL from the dependent Microsoft spec.
"winload.efi" notices this inconsistency, and disables the Device Guard
Virtualization Based Security in Windows Server 2016 and Windows 10 64-bit
Enterprise.
If the platform includes
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf", then MOR will exist
by the time EndOfDxe is reached, and VariableSmm can safely create MORL.
Otherwise, do not create MORL (delete it if it exists), and also prevent
other modules from creating it.
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.tianocore.org/show_bug.cgi?id=727
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1496170
Reported-by: Ladi Prosek <lprosek@redhat.com>
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>
The SetMorLockVariable() function sets "mMorLockPassThru" to TRUE
temporarily, so that it can set the MOR Control Lock variable to
well-formed values without permission checks.
In the next patch, we'll need the same override for deleting the MOR
Control Lock variable; hence obey "mMorLockPassThru" in the deletion
branch of SetVariableCheckHandlerMorLock() as well.
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>
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>
Introduce the MorLockInitAtEndOfDxe() hook, in order to allow
MorLockInit() to delay / queue operations until EndOfDxe. (Or, if the
platform never signals EndOfDxe, until ReadyToBoot.)
Call MorLockInitAtEndOfDxe() whenever we set "mEndOfDxe" to TRUE:
- in VariableRuntimeDxe:
- in the OnReadyToBoot() function,
- in the OnEndOfDxe() function;
- in VariableSmm:
- on the SMM_VARIABLE_FUNCTION_READY_TO_BOOT SMI request,
- in the SmmEndOfDxeCallback() function.
For now, implement MorLockInitAtEndOfDxe() as a no-op in both
VariableRuntimeDxe and VariableSmm.
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>
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>
The MorLockInit() and SetVariableCheckHandlerMor() functions have separate
implementations for VariableRuntimeDxe (= unprivileged, unified
DXE_RUNTIME driver) and VariableSmm (= privileged, DXE_SMM back-end of the
split variable driver).
Move their declarations from "Variable.c" to "PrivilegePolymorphic.h", so
that the compiler enforce that the declarations and the definitions match.
(All C source files with the call sites and the function definitions
already include "PrivilegePolymorphic.h" via "Variable.h".)
At the same time:
- replace two typos in the MorLockInit() description:
- replace "EFI_SUCEESS" with "EFI_SUCCESS",
- replace "MOR Lock Control" with "MOR Control Lock";
- in the SetVariableCheckHandlerMor() description:
- replace @param with @param[in],
- correct the description of the Attributes parameter (suggested by Star
Zeng <star.zeng@intel.com>),
- rewrap the comment to 80 columns.
This change cleans up commit 2f6aa774fe ("MdeModulePkg: Add MorLock to
variable driver.", 2016-01-19).
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>
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>
Microsoft published secure MOR implementation at https://msdn.microsoft.com/en-us/library/windows/hardware/mt270973(v=vs.85).aspx
with revision 2 update. See URL for tech detail.
Previous revision 1 is handled in SecurityPkg\Tcg\ MemoryOverwriteRequestControlLock.
But the VarCheck API can not satisfy revision 2 requirement.
So we decide include MOR lock control into variable driver directly.
This patch add standalone TcgMorLockSmm implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zhang, Chao B" <chao.b.zhang@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19688 6f19259b-4bc3-4df7-8a09-765794883524
Michael D Kinney
Ard Biesheuvel
Zhang, Chao B
Laszlo Ersek
Gary Lin
Yao, Jiewen