From nobody Thu Dec 26 02:00:03 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1507066138165332.0204995767094; Tue, 3 Oct 2017 14:28:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 7F30521E78215; Tue, 3 Oct 2017 14:25:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 48BCB21E781EA for ; Tue, 3 Oct 2017 14:25:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99D2A7E43A; Tue, 3 Oct 2017 21:28:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-122-192.rdu2.redhat.com [10.10.122.192]) by smtp.corp.redhat.com (Postfix) with ESMTP id 39AAC60F82; Tue, 3 Oct 2017 21:28:49 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 99D2A7E43A Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com From: Laszlo Ersek To: edk2-devel-01 Date: Tue, 3 Oct 2017 23:28:34 +0200 Message-Id: <20171003212834.25740-7-lersek@redhat.com> In-Reply-To: <20171003212834.25740-1-lersek@redhat.com> References: <20171003212834.25740-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 03 Oct 2017 21:28:51 +0000 (UTC) Subject: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jiewen Yao , Eric Dong , Star Zeng MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" 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 Cc: Jiewen Yao Cc: Ladi Prosek Cc: Star Zeng Ref: https://bugzilla.redhat.com/show_bug.cgi?id=3D1498159 Suggested-by: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- 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/M= deModulePkg/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 =20 [Protocols] gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES @@ -85,6 +86,8 @@ [Protocols] gEfiSmmVariableProtocolGuid gEfiSmmEndOfDxeProtocolGuid ## NOTIFY gEdkiiSmmVarCheckProtocolGuid ## PRODUCES + gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES + gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES =20 [Guids] ## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c b/M= deModulePkg/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 #include #include +#include #include "Variable.h" =20 typedef struct { @@ -33,6 +34,8 @@ VARIABLE_TYPE mMorVariableType[] =3D { {MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteReques= tControlLockGuid}, }; =20 +BOOLEAN mMorPassThru =3D 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 // =20 + // + // Permit deletion for passthru request. + // + if (((Attributes =3D=3D 0) || (DataSize =3D=3D 0)) && mMorPassThru) { + return EFI_SUCCESS; + } + // // Basic Check // @@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe ( { UINTN MorSize; EFI_STATUS MorStatus; + EFI_STATUS TcgStatus; + VOID *TcgInterface; =20 if (!mMorLockInitializationRequired) { // @@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe ( =20 if (MorStatus =3D=3D EFI_BUFFER_TOO_SMALL) { // - // The MOR variable exists; set the MOR Control Lock variable to repor= t the - // capability to the OS. + // The MOR variable exists. // - SetMorLockVariable (0); - return; + // Some OSes don't follow the TCG's Platform Reset Attack Mitigation s= pec + // in that the OS should never create the MOR variable, only read and = write + // it -- these OSes (unintentionally) create MOR if the platform firmw= are + // does not produce it. Whether this is the case (from the last OS boo= t) + // can be deduced from the absence of the TCG / TCG2 protocols, as edk= 2's + // MOR implementation depends on (one of) those protocols. + // + TcgStatus =3D gBS->LocateProtocol ( + &gEfiTcgProtocolGuid, + NULL, // Registration + &TcgInterface + ); + if (EFI_ERROR (TcgStatus)) { + TcgStatus =3D gBS->LocateProtocol ( + &gEfiTcg2ProtocolGuid, + NULL, // Registration + &TcgInterface + ); + } + + if (!EFI_ERROR (TcgStatus)) { + // + // The MOR variable originates from the platform firmware; set the M= OR + // 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 =3D TRUE; + VariableServiceSetVariable ( + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME, + &gEfiMemoryOverwriteControlDataGuid, + 0, // Attributes + 0, // DataSize + NULL // Data + ); + mMorPassThru =3D FALSE; } =20 // - // The platform does not support the MOR variable. Delete the MOR Control - // Lock variable (should it exists for some reason) and prevent other mo= dules - // 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 =3D TRUE; VariableServiceSetVariable ( --=20 2.14.1.3.gb7cf6e02401b _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel