From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 DA774209603E0 for ; Mon, 28 May 2018 03:57:51 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 255E7402243B; Mon, 28 May 2018 10:57:50 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-186.rdu2.redhat.com [10.10.120.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id C124E210C6CB; Mon, 28 May 2018 10:57:46 +0000 (UTC) To: Andrew Fish , Marvin H?user Cc: "edk2-devel@lists.01.org" , Abhishek Singh , "ruiyu.ni@intel.com" , "eric.dong@intel.com" , "star.zeng@intel.com" References: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> From: Laszlo Ersek Message-ID: <0b422b9a-6995-896d-4166-cd9792e818de@redhat.com> Date: Mon, 28 May 2018 12:57:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Mon, 28 May 2018 10:57:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Mon, 28 May 2018 10:57:50 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: smm lock query X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 10:57:52 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/27/18 22:44, Andrew Fish wrote: > > >> On May 27, 2018, at 9:47 AM, Marvin H?user wrote: >> >> Good day Abhishek, >> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect (exposes the ReadyToLock protocol) and Laszlo for his high-quality answers. >> >> Strictly speaking you are, right, because of the description for the MM protocol: >> "Indicates that MM resources and services that should not be used by the third party code are about[Marvin: (!)] to be locked." >> Practically however, I don't see any issue with the current implementation. Code inside MMRAM is not affected directly by the lock, it is just notified. >> However, either the code or the specification should be slightly updated to be in sync. A code update might require review of the caller assumptions, just to be sure. >> >> I have a different concern though and hope I'm actually overlooking something. >> If I understand the code correctly, it is the Platform BDS that exposes the (S)MmReadyToLock protocol. PiSmmIpl seems to consume that event and lock SMM resources based on the event. >> Because of latter being an event however, I don't think it is, or can be, guaranteed to be the last event group member executing. >> When it is not the last, the "about to be locked" part is not true for any subsequent callbacks, that could actually be a risky break of the specification - if it is. >> If it is a break of the specification, I can only think of letting Platform BDS expose an "internal" event group, which is only caught by PiSmmIpl, which then drives the actual SmmReadyToLock flow. >> This would require updates to all platform trees and hence I would propose a temporary backwards-compatibility. >> >> Any comments? Did I overlook something (I hope)? >> > > Mavvin, > > You are correct there is no guarantee of order in events. Thanks for cc'ing the right folks, as I don't remember all the low level details... > > In general the idea behind the MM code is it only comes from the platform, then by definition that code should be aware when the platform was going to lock MM. In a practical sense any MM module that had a depex evaluate to true would have dispatched in DXE prior to BDS being launched. In general BDS is the code that enumerates PCI and connects devices, thus there is no chance for 3rd party software to run before that point in the boot. So in an abstract sense that lock represents the end of DXE dispatch. This is my understanding as well. gEfiDxeSmmReadyToLockProtocolGuid is installed by Plaform BDS before any non-platform binaries get a chance to run. In terms of the current PlatformBootManagerLib interfaces, that means the protocol should be installed from PlatformBootManagerBeforeConsole() (as noted on the API declaration itself). Thanks Laszlo