public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Eric Dong <eric.dong@intel.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Ladi Prosek <lprosek@redhat.com>, Star Zeng <star.zeng@intel.com>
Subject: [PATCH 5/6] MdeModulePkg/Variable/RuntimeDxe: delay MorLock creation until EndOfDxe
Date: Tue,  3 Oct 2017 23:28:33 +0200	[thread overview]
Message-ID: <20171003212834.25740-6-lersek@redhat.com> (raw)
In-Reply-To: <20171003212834.25740-1-lersek@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>
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 62 ++++++++++++++++++--
 1 file changed, 57 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 1f495f847212..6d14b0042f4d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -45,6 +45,7 @@ typedef enum {
   MorLockStateLocked = 1,
 } MOR_LOCK_STATE;
 
+BOOLEAN         mMorLockInitializationRequired = FALSE;
 UINT8           mMorLockKey[MOR_LOCK_V2_KEY_SIZE];
 BOOLEAN         mMorLockKeyEmpty = TRUE;
 BOOLEAN         mMorLockPassThru = FALSE;
@@ -394,10 +395,8 @@ MorLockInit (
   VOID
   )
 {
-  //
-  // Set variable to report capability to OS
-  //
-  return SetMorLockVariable (0);
+  mMorLockInitializationRequired = TRUE;
+  return EFI_SUCCESS;
 }
 
 /**
@@ -410,7 +409,60 @@ MorLockInitAtEndOfDxe (
   VOID
   )
 {
+  UINTN      MorSize;
+  EFI_STATUS MorStatus;
+
+  if (!mMorLockInitializationRequired) {
+    //
+    // The EFI_SMM_FAULT_TOLERANT_WRITE_PROTOCOL has never been installed, thus
+    // the variable write service is unavailable. Do nothing.
+    //
+    return;
+  }
+
   //
-  // Do nothing.
+  // Check if the MOR variable exists.
   //
+  MorSize = 0;
+  MorStatus = VariableServiceGetVariable (
+                MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,
+                &gEfiMemoryOverwriteControlDataGuid,
+                NULL,                                   // Attributes
+                &MorSize,
+                NULL                                    // Data
+                );
+  //
+  // We provided a zero-sized buffer, so the above call can never succeed.
+  //
+  ASSERT (EFI_ERROR (MorStatus));
+
+  if (MorStatus == EFI_BUFFER_TOO_SMALL) {
+    //
+    // The MOR variable exists; set the MOR Control Lock variable to report the
+    // capability to the OS.
+    //
+    SetMorLockVariable (0);
+    return;
+  }
+
+  //
+  // 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.
+  //
+  mMorLockPassThru = TRUE;
+  VariableServiceSetVariable (
+    MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,
+    &gEfiMemoryOverwriteRequestControlLockGuid,
+    0,                                          // Attributes
+    0,                                          // DataSize
+    NULL                                        // Data
+    );
+  mMorLockPassThru = FALSE;
+
+  VariableLockRequestToLock (
+    NULL,                                       // This
+    MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,
+    &gEfiMemoryOverwriteRequestControlLockGuid
+    );
 }
-- 
2.14.1.3.gb7cf6e02401b




  parent reply	other threads:[~2017-10-03 21:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 21:28 [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock inconsistency Laszlo Ersek
2017-10-03 21:28 ` [PATCH 1/6] MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new header Laszlo Ersek
2017-10-03 21:28 ` [PATCH 2/6] MdeModulePkg/Variable/RuntimeDxe: move MOR func. declarations to header Laszlo Ersek
2017-10-09  6:55   ` Zeng, Star
2017-10-09 12:47     ` Laszlo Ersek
2017-10-03 21:28 ` [PATCH 3/6] MdeModulePkg/Variable/RuntimeDxe: introduce MorLockInitAtEndOfDxe() hook Laszlo Ersek
2017-10-03 21:28 ` [PATCH 4/6] MdeModulePkg/Variable/RuntimeDxe: permit MorLock deletion for passthru req Laszlo Ersek
2017-10-03 21:28 ` Laszlo Ersek [this message]
2017-10-03 21:28 ` [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable Laszlo Ersek
2017-10-09  7:12   ` Zeng, Star
2017-10-09 15:20     ` Laszlo Ersek
2017-10-10  4:15       ` Yao, Jiewen
2017-10-10 13:14         ` Zeng, Star
2017-10-04  1:18 ` [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock inconsistency Yao, Jiewen
2017-10-04 10:39   ` Laszlo Ersek
2017-10-04 12:24     ` Ladi Prosek
2017-10-10  4:17     ` Yao, Jiewen
2017-10-10 10:09       ` Laszlo Ersek
2017-10-10 12:16         ` Zeng, Star
2017-10-05  7:42 ` Zeng, Star
2017-10-05  7:57   ` Laszlo Ersek
2017-10-05  9:12     ` Yao, Jiewen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003212834.25740-6-lersek@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox