From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 618832095B09A for ; Tue, 10 Oct 2017 06:51:51 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 06:55:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,505,1500966000"; d="scan'208";a="1023660436" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 10 Oct 2017 06:55:16 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 10 Oct 2017 06:54:49 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 10 Oct 2017 06:54:48 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.175]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.213]) with mapi id 14.03.0319.002; Tue, 10 Oct 2017 21:54:46 +0800 From: "Zeng, Star" To: Laszlo Ersek , edk2-devel-01 CC: "Dong, Eric" , "Yao, Jiewen" , "Zeng, Star" Thread-Topic: [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of SMM Thread-Index: AQHTQcsymAp4aNQ81UGwQZlp6QvOb6LdGeHQ Date: Tue, 10 Oct 2017 13:54:46 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B980020@shsmsx102.ccr.corp.intel.com> References: <20171010132443.11383-1-lersek@redhat.com> In-Reply-To: <20171010132443.11383-1-lersek@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the absence of SMM 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: , X-List-Received-Date: Tue, 10 Oct 2017 13:51:51 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could you help make the code consistent to call VariableServiceSetVariable(= ) for the Attributes? One original for MorLock is using real attributes, the new you added for Mo= r will use 0 attributes. How about to both use 0 attributes. Another question, why empty MorLockInitAtEndOfDxe() needs to be implemented= in TcgMorLockDxe.c and called in VariableDxe.c? Thanks, Star -----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com]=20 Sent: Tuesday, October 10, 2017 9:25 PM To: edk2-devel-01 Cc: Dong, Eric ; Yao, Jiewen ; Z= eng, Star Subject: [PATCH] MdeModulePkg/Variable/RuntimeDxe: delete & lock MOR in the= absence of SMM VariableRuntimeDxe deletes and locks the MorLock variable in MorLockInit(), with the argument that any protection provided by MorLock can be circumvented if MorLock can be overwritten by unprivileged code (i.e., outside of SMM). Extend the argument and the logic to the MOR variable, which is supposed to be protected by MorLock. This change was suggested by Star; it is inspired by earlier VariableSmm commit fda8f631edbb ("MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable", 2017-10-03). Cc: Eric Dong Cc: Jiewen Yao Cc: Star Zeng Suggested-by: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- Notes: Repo: https://github.com/lersek/edk2.git Branch: del_and_lock_mor_without_smm MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c | 24 ++++++++++= ++++++++++ 1 file changed, 24 insertions(+) diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c b/M= deModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c index 7142e2da2073..1610c7aa0706 100644 --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c @@ -69,29 +69,53 @@ EFI_STATUS MorLockInit ( VOID ) { // // Always clear variable to report unsupported to OS. // The reason is that the DXE version is not proper to provide *protecti= on*. // BIOS should use SMM version variable driver to provide such capabilit= y. // VariableServiceSetVariable ( MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARI= ABLE_RUNTIME_ACCESS, 0, NULL ); =20 // // Need set this variable to be read-only to prevent other module set it= . // VariableLockRequestToLock (&mVariableLock, MEMORY_OVERWRITE_REQUEST_CONT= ROL_LOCK_NAME, &gEfiMemoryOverwriteRequestControlLockGuid); + + // + // The MOR variable can effectively improve platform security only when = the + // MorLock variable protects the MOR variable. In turn MorLock cannot be= made + // secure without SMM support in the platform firmware (see above). + // + // Thus, delete the MOR variable, should it exist for any reason (some O= Ses + // are known to create MOR unintentionally, in an attempt to set it), th= en + // also lock the MOR variable, in order to prevent other modules from + // creating it. + // + VariableServiceSetVariable ( + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME, + &gEfiMemoryOverwriteControlDataGuid, + 0, // Attributes + 0, // DataSize + NULL // Data + ); + VariableLockRequestToLock ( + &mVariableLock, + MEMORY_OVERWRITE_REQUEST_VARIABLE_NAME, + &gEfiMemoryOverwriteControlDataGuid + ); + return EFI_SUCCESS; } =20 /** Delayed initialization for MOR Control Lock at EndOfDxe. =20 This function performs any operations queued by MorLockInit(). **/ --=20 2.14.1.3.gb7cf6e02401b