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>
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 3 +
MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 ++++++++++++++++++--
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
index 404164366579..69966f0d37ee 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
@@ -74,6 +74,7 @@ [LibraryClasses]
SmmMemLib
AuthVariableLib
VarCheckLib
+ UefiBootServicesTableLib
[Protocols]
gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
@@ -85,6 +86,8 @@ [Protocols]
gEfiSmmVariableProtocolGuid
gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
+ gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
+ gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
[Guids]
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 6d14b0042f4d..0a0281e44bc1 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#include <Library/DebugLib.h>
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include "Variable.h"
typedef struct {
@@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] = {
{MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid},
};
+BOOLEAN mMorPassThru = FALSE;
+
#define MOR_LOCK_DATA_UNLOCKED 0x0
#define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
#define MOR_LOCK_DATA_LOCKED_WITH_KEY 0x2
@@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
// Mor Variable
//
+ //
+ // Permit deletion for passthru request.
+ //
+ if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
+ return EFI_SUCCESS;
+ }
+
//
// Basic Check
//
@@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe (
{
UINTN MorSize;
EFI_STATUS MorStatus;
+ EFI_STATUS TcgStatus;
+ VOID *TcgInterface;
if (!mMorLockInitializationRequired) {
//
@@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
if (MorStatus == EFI_BUFFER_TOO_SMALL) {
//
- // The MOR variable exists; set the MOR Control Lock variable to report the
- // capability to the OS.
+ // The MOR variable exists.
//
- SetMorLockVariable (0);
- return;
+ // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
+ // in that the OS should never create the MOR variable, only read and write
+ // it -- these OSes (unintentionally) create MOR if the platform firmware
+ // does not produce it. Whether this is the case (from the last OS boot)
+ // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
+ // MOR implementation depends on (one of) those protocols.
+ //
+ TcgStatus = gBS->LocateProtocol (
+ &gEfiTcgProtocolGuid,
+ NULL, // Registration
+ &TcgInterface
+ );
+ if (EFI_ERROR (TcgStatus)) {
+ TcgStatus = gBS->LocateProtocol (
+ &gEfiTcg2ProtocolGuid,
+ NULL, // Registration
+ &TcgInterface
+ );
+ }
+
+ if (!EFI_ERROR (TcgStatus)) {
+ //
+ // The MOR variable originates from the platform firmware; set the MOR
+ // Control Lock variable to report the locking capability to the OS.
+ //
+ SetMorLockVariable (0);
+ return;
+ }
+
+ //
+ // The MOR variable's origin is inexplicable; delete it.
+ //
+ DEBUG ((
+ DEBUG_WARN,
+ "%a: deleting unexpected / unsupported variable %g:%s\n",
+ __FUNCTION__,
+ &gEfiMemoryOverwriteControlDataGuid,
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME
+ ));
+
+ mMorPassThru = TRUE;
+ VariableServiceSetVariable (
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+ &gEfiMemoryOverwriteControlDataGuid,
+ 0, // Attributes
+ 0, // DataSize
+ NULL // Data
+ );
+ mMorPassThru = FALSE;
}
//
- // The platform does not support the MOR variable. Delete the MOR Control
- // Lock variable (should it exists for some reason) and prevent other modules
- // from creating it.
+ // The MOR variable is absent; the platform firmware does not support it.
+ // Lock the variable so that no other module may create it.
+ //
+ VariableLockRequestToLock (
+ NULL, // This
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+ &gEfiMemoryOverwriteControlDataGuid
+ );
+
+ //
+ // Delete the MOR Control Lock variable too (should it exists for some
+ // reason) and prevent other modules from creating it.
//
mMorLockPassThru = TRUE;
VariableServiceSetVariable (
--
2.14.1.3.gb7cf6e02401b
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo,
Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and lock OS-created MOR variable?
Thanks,
Star
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Wednesday, October 4, 2017 5:29 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Dong, Eric <eric.dong@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Ladi Prosek <lprosek@redhat.com>; Zeng, Star <star.zeng@intel.com>
Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
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>
---
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 3 + MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 ++++++++++++++++++--
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
index 404164366579..69966f0d37ee 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
@@ -74,6 +74,7 @@ [LibraryClasses]
SmmMemLib
AuthVariableLib
VarCheckLib
+ UefiBootServicesTableLib
[Protocols]
gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
@@ -85,6 +86,8 @@ [Protocols]
gEfiSmmVariableProtocolGuid
gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
+ gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
+ gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
[Guids]
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 6d14b0042f4d..0a0281e44bc1 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#include <Library/DebugLib.h>
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include "Variable.h"
typedef struct {
@@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] = {
{MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid},
};
+BOOLEAN mMorPassThru = FALSE;
+
#define MOR_LOCK_DATA_UNLOCKED 0x0
#define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
#define MOR_LOCK_DATA_LOCKED_WITH_KEY 0x2
@@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
// Mor Variable
//
+ //
+ // Permit deletion for passthru request.
+ //
+ if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
+ return EFI_SUCCESS;
+ }
+
//
// Basic Check
//
@@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe ( {
UINTN MorSize;
EFI_STATUS MorStatus;
+ EFI_STATUS TcgStatus;
+ VOID *TcgInterface;
if (!mMorLockInitializationRequired) {
//
@@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
if (MorStatus == EFI_BUFFER_TOO_SMALL) {
//
- // The MOR variable exists; set the MOR Control Lock variable to report the
- // capability to the OS.
+ // The MOR variable exists.
//
- SetMorLockVariable (0);
- return;
+ // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
+ // in that the OS should never create the MOR variable, only read and write
+ // it -- these OSes (unintentionally) create MOR if the platform firmware
+ // does not produce it. Whether this is the case (from the last OS boot)
+ // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
+ // MOR implementation depends on (one of) those protocols.
+ //
+ TcgStatus = gBS->LocateProtocol (
+ &gEfiTcgProtocolGuid,
+ NULL, // Registration
+ &TcgInterface
+ );
+ if (EFI_ERROR (TcgStatus)) {
+ TcgStatus = gBS->LocateProtocol (
+ &gEfiTcg2ProtocolGuid,
+ NULL, // Registration
+ &TcgInterface
+ );
+ }
+
+ if (!EFI_ERROR (TcgStatus)) {
+ //
+ // The MOR variable originates from the platform firmware; set the MOR
+ // Control Lock variable to report the locking capability to the OS.
+ //
+ SetMorLockVariable (0);
+ return;
+ }
+
+ //
+ // The MOR variable's origin is inexplicable; delete it.
+ //
+ DEBUG ((
+ DEBUG_WARN,
+ "%a: deleting unexpected / unsupported variable %g:%s\n",
+ __FUNCTION__,
+ &gEfiMemoryOverwriteControlDataGuid,
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME
+ ));
+
+ mMorPassThru = TRUE;
+ VariableServiceSetVariable (
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+ &gEfiMemoryOverwriteControlDataGuid,
+ 0, // Attributes
+ 0, // DataSize
+ NULL // Data
+ );
+ mMorPassThru = FALSE;
}
//
- // The platform does not support the MOR variable. Delete the MOR Control
- // Lock variable (should it exists for some reason) and prevent other modules
- // from creating it.
+ // The MOR variable is absent; the platform firmware does not support it.
+ // Lock the variable so that no other module may create it.
+ //
+ VariableLockRequestToLock (
+ NULL, // This
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+ &gEfiMemoryOverwriteControlDataGuid
+ );
+
+ //
+ // Delete the MOR Control Lock variable too (should it exists for
+ some // reason) and prevent other modules from creating it.
//
mMorLockPassThru = TRUE;
VariableServiceSetVariable (
--
2.14.1.3.gb7cf6e02401b
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
>
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and lock OS-created MOR variable?
Maybe -- I'm not sure.
If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.
How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.
So I can only give you a conditional answer:
(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().
(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)
(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).
So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].
Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)
Jiewen, what do you say?
Thanks!
Laszlo
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Dong, Eric <eric.dong@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Ladi Prosek <lprosek@redhat.com>; Zeng, Star <star.zeng@intel.com>
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
>
> 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>
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 3 + MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 ++++++++++++++++++--
> 2 files changed, 77 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> index 404164366579..69966f0d37ee 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> @@ -74,6 +74,7 @@ [LibraryClasses]
> SmmMemLib
> AuthVariableLib
> VarCheckLib
> + UefiBootServicesTableLib
>
> [Protocols]
> gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
> @@ -85,6 +86,8 @@ [Protocols]
> gEfiSmmVariableProtocolGuid
> gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
> gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
> + gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
> + gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
>
> [Guids]
> ## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> index 6d14b0042f4d..0a0281e44bc1 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include <Library/DebugLib.h>
> #include <Library/BaseLib.h>
> #include <Library/BaseMemoryLib.h>
> +#include <Library/UefiBootServicesTableLib.h>
> #include "Variable.h"
>
> typedef struct {
> @@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] = {
> {MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid},
> };
>
> +BOOLEAN mMorPassThru = FALSE;
> +
> #define MOR_LOCK_DATA_UNLOCKED 0x0
> #define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
> #define MOR_LOCK_DATA_LOCKED_WITH_KEY 0x2
> @@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
> // Mor Variable
> //
>
> + //
> + // Permit deletion for passthru request.
> + //
> + if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
> + return EFI_SUCCESS;
> + }
> +
> //
> // Basic Check
> //
> @@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe ( {
> UINTN MorSize;
> EFI_STATUS MorStatus;
> + EFI_STATUS TcgStatus;
> + VOID *TcgInterface;
>
> if (!mMorLockInitializationRequired) {
> //
> @@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
>
> if (MorStatus == EFI_BUFFER_TOO_SMALL) {
> //
> - // The MOR variable exists; set the MOR Control Lock variable to report the
> - // capability to the OS.
> + // The MOR variable exists.
> //
> - SetMorLockVariable (0);
> - return;
> + // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
> + // in that the OS should never create the MOR variable, only read and write
> + // it -- these OSes (unintentionally) create MOR if the platform firmware
> + // does not produce it. Whether this is the case (from the last OS boot)
> + // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
> + // MOR implementation depends on (one of) those protocols.
> + //
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcgProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + if (EFI_ERROR (TcgStatus)) {
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcg2ProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + }
> +
> + if (!EFI_ERROR (TcgStatus)) {
> + //
> + // The MOR variable originates from the platform firmware; set the MOR
> + // Control Lock variable to report the locking capability to the OS.
> + //
> + SetMorLockVariable (0);
> + return;
> + }
> +
> + //
> + // The MOR variable's origin is inexplicable; delete it.
> + //
> + DEBUG ((
> + DEBUG_WARN,
> + "%a: deleting unexpected / unsupported variable %g:%s\n",
> + __FUNCTION__,
> + &gEfiMemoryOverwriteControlDataGuid,
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME
> + ));
> +
> + mMorPassThru = TRUE;
> + VariableServiceSetVariable (
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid,
> + 0, // Attributes
> + 0, // DataSize
> + NULL // Data
> + );
> + mMorPassThru = FALSE;
> }
>
> //
> - // The platform does not support the MOR variable. Delete the MOR Control
> - // Lock variable (should it exists for some reason) and prevent other modules
> - // from creating it.
> + // The MOR variable is absent; the platform firmware does not support it.
> + // Lock the variable so that no other module may create it.
> + //
> + VariableLockRequestToLock (
> + NULL, // This
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid
> + );
> +
> + //
> + // Delete the MOR Control Lock variable too (should it exists for
> + some // reason) and prevent other modules from creating it.
> //
> mMorLockPassThru = TRUE;
> VariableServiceSetVariable (
> --
> 2.14.1.3.gb7cf6e02401b
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Yes, option a) looks good to me. A simple patch is good enough in this case.
In addition, this original patch passed our validation with MOR and MORL.
The series is reviewed-by: Jiewen.Yao@intel.com<mailto:Jiewen.Yao@intel.com>
We can treat a) in another patch.
Thank you
Yao Jiewen
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Monday, October 9, 2017 11:21 PM
To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Dong, Eric <eric.dong@intel.com>
Subject: Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
>
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and lock OS-created MOR variable?
Maybe -- I'm not sure.
If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.
How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.
So I can only give you a conditional answer:
(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().
(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)
(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).
So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].
Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)
Jiewen, what do you say?
Thanks!
Laszlo
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
> Cc: Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Ladi Prosek <lprosek@redhat.com<mailto:lprosek@redhat.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
>
> 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<mailto:eric.dong@intel.com>>
> Cc: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Cc: Ladi Prosek <lprosek@redhat.com<mailto:lprosek@redhat.com>>
> Cc: Star Zeng <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
> Suggested-by: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 3 + MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 ++++++++++++++++++--
> 2 files changed, 77 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> index 404164366579..69966f0d37ee 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> @@ -74,6 +74,7 @@ [LibraryClasses]
> SmmMemLib
> AuthVariableLib
> VarCheckLib
> + UefiBootServicesTableLib
>
> [Protocols]
> gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
> @@ -85,6 +86,8 @@ [Protocols]
> gEfiSmmVariableProtocolGuid
> gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
> gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
> + gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
> + gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
>
> [Guids]
> ## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> index 6d14b0042f4d..0a0281e44bc1 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include <Library/DebugLib.h>
> #include <Library/BaseLib.h>
> #include <Library/BaseMemoryLib.h>
> +#include <Library/UefiBootServicesTableLib.h>
> #include "Variable.h"
>
> typedef struct {
> @@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] = {
> {MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid},
> };
>
> +BOOLEAN mMorPassThru = FALSE;
> +
> #define MOR_LOCK_DATA_UNLOCKED 0x0
> #define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
> #define MOR_LOCK_DATA_LOCKED_WITH_KEY 0x2
> @@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
> // Mor Variable
> //
>
> + //
> + // Permit deletion for passthru request.
> + //
> + if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
> + return EFI_SUCCESS;
> + }
> +
> //
> // Basic Check
> //
> @@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe ( {
> UINTN MorSize;
> EFI_STATUS MorStatus;
> + EFI_STATUS TcgStatus;
> + VOID *TcgInterface;
>
> if (!mMorLockInitializationRequired) {
> //
> @@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
>
> if (MorStatus == EFI_BUFFER_TOO_SMALL) {
> //
> - // The MOR variable exists; set the MOR Control Lock variable to report the
> - // capability to the OS.
> + // The MOR variable exists.
> //
> - SetMorLockVariable (0);
> - return;
> + // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
> + // in that the OS should never create the MOR variable, only read and write
> + // it -- these OSes (unintentionally) create MOR if the platform firmware
> + // does not produce it. Whether this is the case (from the last OS boot)
> + // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
> + // MOR implementation depends on (one of) those protocols.
> + //
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcgProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + if (EFI_ERROR (TcgStatus)) {
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcg2ProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + }
> +
> + if (!EFI_ERROR (TcgStatus)) {
> + //
> + // The MOR variable originates from the platform firmware; set the MOR
> + // Control Lock variable to report the locking capability to the OS.
> + //
> + SetMorLockVariable (0);
> + return;
> + }
> +
> + //
> + // The MOR variable's origin is inexplicable; delete it.
> + //
> + DEBUG ((
> + DEBUG_WARN,
> + "%a: deleting unexpected / unsupported variable %g:%s\n",
> + __FUNCTION__,
> + &gEfiMemoryOverwriteControlDataGuid,
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME
> + ));
> +
> + mMorPassThru = TRUE;
> + VariableServiceSetVariable (
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid,
> + 0, // Attributes
> + 0, // DataSize
> + NULL // Data
> + );
> + mMorPassThru = FALSE;
> }
>
> //
> - // The platform does not support the MOR variable. Delete the MOR Control
> - // Lock variable (should it exists for some reason) and prevent other modules
> - // from creating it.
> + // The MOR variable is absent; the platform firmware does not support it.
> + // Lock the variable so that no other module may create it.
> + //
> + VariableLockRequestToLock (
> + NULL, // This
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid
> + );
> +
> + //
> + // Delete the MOR Control Lock variable too (should it exists for
> + some // reason) and prevent other modules from creating it.
> //
> mMorLockPassThru = TRUE;
> VariableServiceSetVariable (
> --
> 2.14.1.3.gb7cf6e02401b
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
I agree with this direction a) if we think MOR with non-SMM is useless.
Thanks,
Star
From: Yao, Jiewen
Sent: Tuesday, October 10, 2017 12:15 PM
To: Laszlo Ersek <lersek@redhat.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Dong, Eric <eric.dong@intel.com>
Subject: RE: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
Yes, option a) looks good to me. A simple patch is good enough in this case.
In addition, this original patch passed our validation with MOR and MORL.
The series is reviewed-by: Jiewen.Yao@intel.com<mailto:Jiewen.Yao@intel.com>
We can treat a) in another patch.
Thank you
Yao Jiewen
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Monday, October 9, 2017 11:21 PM
To: Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>
Subject: Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
>
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and lock OS-created MOR variable?
Maybe -- I'm not sure.
If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.
How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.
So I can only give you a conditional answer:
(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().
(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)
(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).
So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].
Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)
Jiewen, what do you say?
Thanks!
Laszlo
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
> Cc: Dong, Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Ladi Prosek <lprosek@redhat.com<mailto:lprosek@redhat.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable
>
> 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<mailto:eric.dong@intel.com>>
> Cc: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Cc: Ladi Prosek <lprosek@redhat.com<mailto:lprosek@redhat.com>>
> Cc: Star Zeng <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
> Suggested-by: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 3 + MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 ++++++++++++++++++--
> 2 files changed, 77 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> index 404164366579..69966f0d37ee 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> @@ -74,6 +74,7 @@ [LibraryClasses]
> SmmMemLib
> AuthVariableLib
> VarCheckLib
> + UefiBootServicesTableLib
>
> [Protocols]
> gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
> @@ -85,6 +86,8 @@ [Protocols]
> gEfiSmmVariableProtocolGuid
> gEfiSmmEndOfDxeProtocolGuid ## NOTIFY
> gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
> + gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
> + gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
>
> [Guids]
> ## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> index 6d14b0042f4d..0a0281e44bc1 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
> @@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include <Library/DebugLib.h>
> #include <Library/BaseLib.h>
> #include <Library/BaseMemoryLib.h>
> +#include <Library/UefiBootServicesTableLib.h>
> #include "Variable.h"
>
> typedef struct {
> @@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] = {
> {MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid},
> };
>
> +BOOLEAN mMorPassThru = FALSE;
> +
> #define MOR_LOCK_DATA_UNLOCKED 0x0
> #define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
> #define MOR_LOCK_DATA_LOCKED_WITH_KEY 0x2
> @@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
> // Mor Variable
> //
>
> + //
> + // Permit deletion for passthru request.
> + //
> + if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
> + return EFI_SUCCESS;
> + }
> +
> //
> // Basic Check
> //
> @@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe ( {
> UINTN MorSize;
> EFI_STATUS MorStatus;
> + EFI_STATUS TcgStatus;
> + VOID *TcgInterface;
>
> if (!mMorLockInitializationRequired) {
> //
> @@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
>
> if (MorStatus == EFI_BUFFER_TOO_SMALL) {
> //
> - // The MOR variable exists; set the MOR Control Lock variable to report the
> - // capability to the OS.
> + // The MOR variable exists.
> //
> - SetMorLockVariable (0);
> - return;
> + // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
> + // in that the OS should never create the MOR variable, only read and write
> + // it -- these OSes (unintentionally) create MOR if the platform firmware
> + // does not produce it. Whether this is the case (from the last OS boot)
> + // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
> + // MOR implementation depends on (one of) those protocols.
> + //
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcgProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + if (EFI_ERROR (TcgStatus)) {
> + TcgStatus = gBS->LocateProtocol (
> + &gEfiTcg2ProtocolGuid,
> + NULL, // Registration
> + &TcgInterface
> + );
> + }
> +
> + if (!EFI_ERROR (TcgStatus)) {
> + //
> + // The MOR variable originates from the platform firmware; set the MOR
> + // Control Lock variable to report the locking capability to the OS.
> + //
> + SetMorLockVariable (0);
> + return;
> + }
> +
> + //
> + // The MOR variable's origin is inexplicable; delete it.
> + //
> + DEBUG ((
> + DEBUG_WARN,
> + "%a: deleting unexpected / unsupported variable %g:%s\n",
> + __FUNCTION__,
> + &gEfiMemoryOverwriteControlDataGuid,
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME
> + ));
> +
> + mMorPassThru = TRUE;
> + VariableServiceSetVariable (
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid,
> + 0, // Attributes
> + 0, // DataSize
> + NULL // Data
> + );
> + mMorPassThru = FALSE;
> }
>
> //
> - // The platform does not support the MOR variable. Delete the MOR Control
> - // Lock variable (should it exists for some reason) and prevent other modules
> - // from creating it.
> + // The MOR variable is absent; the platform firmware does not support it.
> + // Lock the variable so that no other module may create it.
> + //
> + VariableLockRequestToLock (
> + NULL, // This
> + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
> + &gEfiMemoryOverwriteControlDataGuid
> + );
> +
> + //
> + // Delete the MOR Control Lock variable too (should it exists for
> + some // reason) and prevent other modules from creating it.
> //
> mMorLockPassThru = TRUE;
> VariableServiceSetVariable (
> --
> 2.14.1.3.gb7cf6e02401b
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
© 2016 - 2024 Red Hat, Inc.