+ // Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec\r
+ // in that the OS should never create the MOR variable, only read and write\r
+ // it -- these OSes (unintentionally) create MOR if the platform firmware\r
+ // does not produce it. Whether this is the case (from the last OS boot)\r
+ // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's\r
+ // MOR implementation depends on (one of) those protocols.\r
+ //\r
+ TcgStatus = gBS->LocateProtocol (\r
+ &gEfiTcg2ProtocolGuid,\r
+ NULL, // Registration\r
+ &TcgInterface\r
+ );\r
+ if (EFI_ERROR (TcgStatus)) {\r
+ TcgStatus = gBS->LocateProtocol (\r
+ &gEfiTcgProtocolGuid,\r
+ NULL, // Registration\r
+ &TcgInterface\r
+ );\r
+ }\r
+\r
+ if (!EFI_ERROR (TcgStatus)) {\r
+ //\r
+ // The MOR variable originates from the platform firmware; set the MOR\r
+ // Control Lock variable to report the locking capability to the OS.\r
+ //\r
+ SetMorLockVariable (0);\r
+ return;\r
+ }\r
+\r
+ //\r
+ // The MOR variable's origin is inexplicable; delete it.\r
+ //\r
+ DEBUG ((\r
+ DEBUG_WARN,\r
+ "%a: deleting unexpected / unsupported variable %g:%s\n",\r
+ __FUNCTION__,\r
+ &gEfiMemoryOverwriteControlDataGuid,\r
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME\r
+ ));\r
+\r
+ mMorPassThru = TRUE;\r
+ VariableServiceSetVariable (\r
+ MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME,\r
+ &gEfiMemoryOverwriteControlDataGuid,\r
+ 0, // Attributes\r
+ 0, // DataSize\r
+ NULL // Data\r
+ );\r
+ mMorPassThru = FALSE;\r