From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.25; helo=mail-in2.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 6790B208F7A45 for ; Tue, 29 May 2018 07:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527605651; x=2391519251; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+PdJRcVe739DiztvPsoF9tKRF80/FTPXsgyE3oOf7nU=; b=ZKKqtfDCurv3b/joPgsWwgcNTsCi7d2G/VJPeEtJF7BW3ae330Hx56sLqkaC+nDo k9VtsqsEj6GkTGaiNTiO9CmRume9CE4JhmaUQs1OvRcMlD/Z0M6H3BpksFkQHjXJ O4jJFXY/r5pu5t7qadeCVraD8bQjaY/b+YLxX4pixLVdnIIVoVHslCCnPvjXAkOj LpTC93LCS/6bt1QPfmuzkYtMkYWYbCAYy+IHP+OCjTqlyCZg/rwSPt++//pXDhQe Nc5W2GMQ/KFoEO2Btu0j/+xEv8W9ufelL/aIX0FOTFRHL9vyqHokVe+hLXmPU3Wc SDujuDjWNNzg1Q9j0ap3bA==; X-AuditID: 11973e11-83bff700000035ff-55-5b0d69920645 Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id E8.95.13823.2996D0B5; Tue, 29 May 2018 07:54:10 -0700 (PDT) MIME-version: 1.0 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9H009ROW2A61A0@mr2-mtap-s01.rno.apple.com>; Tue, 29 May 2018 07:54:10 -0700 (PDT) Received: from [17.235.42.11] (unknown [17.235.42.11]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9H00BUPW281O20@nwk-mmpp-sz10.apple.com>; Tue, 29 May 2018 07:54:10 -0700 (PDT) X-Va-A: X-Va-T-CD: 24c6376f5a5493ec23d576f81300b693 X-Va-E-CD: 180a5a6e85d6c831d5b48afa05384183 X-Va-R-CD: 4bb4db1280b847e4cbdc5a90350b1a38 X-Va-CD: 0 X-Va-ID: 150418d0-3267-4975-b54f-93320f6459a0 X-V-A: X-V-T-CD: f0356be06219a7b9423582916068c2be X-V-E-CD: 180a5a6e85d6c831d5b48afa05384183 X-V-R-CD: 4bb4db1280b847e4cbdc5a90350b1a38 X-V-CD: 0 X-V-ID: 2baf1dbb-47e2-4934-b528-bb9453541076 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-29_05:,, signatures=0 Sender: afish@apple.com From: Andrew Fish Message-id: <7C590FE7-9086-41B2-95E4-E5AB1812933F@apple.com> Date: Tue, 29 May 2018 07:54:07 -0700 In-reply-to: Cc: "Yao, Jiewen" , "Zeng, Star" , Marvin H?user , "edk2-devel@lists.01.org" , Laszlo Ersek , "Ni, Ruiyu" , "Dong, Eric" To: Abhishek Singh References: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> <0b422b9a-6995-896d-4166-cd9792e818de@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BB47EC2@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503AC13EC5@shsmsx102.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR3PyoVXdSJm+0wedGa4vr3ycwWuw5dJTZ YvOLYIt1Hz0slh3bwWLx9v9VdouXPavZLfb1WjtweBz6dY3FY/Gel0we3bP/sXhsfv2C2eP9 vqtsAaxRXDYpqTmZZalF+nYJXBnzrs9jLfh7lqli94sVLA2MWxcwdTFyckgImEgs//8GyObi EBI4wCTx+uhcNpAEr4CgxI/J91hAbGaBMIlD/94xQxStZ5Lof3iVFSQhJNDPJPHsNz/EJHaJ P792sEDY2hKbu7aww9jLl89ig7F/7poOFeeSWLD1NCuErSvx6NUlqF42ifUnlkBdpyVx4GsT I4z99tJNNhi7c8tbqF5OifNfJkLN1JGY1XGVGcLOljh+fS9Yr7CAuMS7M5vA4mwCyhIr5n9g h3jSRqJ9D0yNksSV48/AbBYBVYmd7+eAzecUCJbYe7eLDeR5ZoG5TBIP9hwAO1QEaND3O9vZ IKHSySpx/eImqIuUJP7vOsI8gVF2FlJIzkIKyVmMHEC2usSUKbkQYW2JJ+8usELYahILfy9i QhZfwMi2ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMo2Uy3E9zBeHyV1SFGAQ5GJR5egwjeaCHW xLLiytxDjNIcLErivDWTOaKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJbKad2/UOKYv+NO 3eOT+zcYz3s7eZvp5mCx//4KfRvCr1eud3jAYLbqbmNDe/iZmat9RC3X7Ne59n7dufN8Z4Pu trZsZV3rffbGu+zU76r30zfazuzz1jOcIcTiP+dv6IR5U+NbnrIURa+yfXzGYUvlvj9amxqV lQuvvj42leHF+vVGCRz/WB8osRRnJBpqMRcVJwIAspvnexcDAAA= X-Content-Filtered-By: Mailman/MimeDel 2.1.26 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: Tue, 29 May 2018 14:54:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On May 28, 2018, at 10:17 PM, Abhishek Singh wrote: >=20 > Thanks, Jiewen and Star. I was able to figure out that smrr was = preventing me from accessing the contents of smram. It seems to me that = this violates the EFI_MM_ACCESS_PROTOCOL protocol. I have talked to = the edk2-platform maintainers about this on a private thread, but, of = course, I may be mistaken. >=20 > I agree that smm is a runtime environment, but you must also agree = that there is an initialization or loading phase in which all the smi = handlers are loaded into smram. Theoretically, new handlers may keep = getting installed as smi's are received but I doubt that this is the = case. There must be a point at which the code (not necessarily the data) = is supposed to be fixed in smram. My guess is that that point is after = the SMI handlers have responded to the SmmReadyToLock event, but I would = like to know if you disagree. >=20 > I am definitely not seeking to add the smram dumping code as a = production feature. I am merely interested in using it for my research. >=20 > I may have to resort to writing an smm driver, as you suggest Jiewen, = but currently I am just trying to dump smram contents from smm ipl, = having disabled smrr in SmmCpuFeaturesLib. The problem, in both cases, = is that the smram range is quite large (around 8 MB) and cannot fit in a = single UEFI variable. Do you have any suggestions on how to actually = dump out this large range? >=20 Abhishek, If you can write a variable you can write to memory. You can allocate = EfiACPIMemoryNVS memory, and that memory will not be used by the OS. = Then the variable can point to that memory region.=20 Thanks, Andrew Fish > Thanks again, > Abhishek >=20 >=20 > On Mon, May 28, 2018 at 10:21 PM, Yao, Jiewen > wrote: > Let me share my thought. >=20 > 1) =46rom interface point of view, ReadyToLock means it is the = last time to lock. But it does not mean it must be open before. >=20 > As implementation choice, a platform MAY lock it earlier. >=20 > =20 >=20 > Also SMRR may force the SMRAM invisible to outside SMRAM, even with = D_OPEN set. >=20 > =20 >=20 > 2) Dumping SMRAM exposes the secret inside of SMRAM, I would = treat it as debug feature only, not a production. >=20 > =20 >=20 > If you want to debug, you can add a debug SMM driver and expose an = interface to copy SMRAM content out. >=20 > =C2=A0 <> > Thank you >=20 > Yao Jiewen >=20 > =20 >=20 > <>From: Zeng, Star=20 > Sent: Monday, May 28, 2018 6:16 PM > To: Abhishek Singh >; Marvin = H?user > > Cc: edk2-devel@lists.01.org ; Laszlo = Ersek >; afish@apple.com = ; Ni, Ruiyu >; Dong, Eric >; Zeng, Star >; Yao, Jiewen > > Subject: RE: [edk2] smm lock query >=20 > =20 >=20 > I do not see issue according to the spec. >=20 > Platform should know when to signal DxeSmmReadyToLock (after = EndOfDxe). >=20 > DxeSmmReadyToLock event is to notify DXE handlers. >=20 > Modules are responsible to lock or protect their resource and effect = the appropriate protections in their notification handlers. >=20 > SmmIplGuidedEventNotify is used to inform SMM environment to signal = SmmReadyToLock. >=20 > SmmReadyToLock event is to notify SMM handlers. >=20 > =20 >=20 > DXE handlers could not touch SMRAM (after SMRAM is locked or even = after SMRR is configured in PiSmmCpuDxeSmm if I know it is correct). >=20 > =20 >=20 > =E2=80=9CThis protocol in tandem with the End of DXE Event facilitates = transition of the platform from the environment where all of the = components are under the authority of the platform manufacturer to the = environment where third party extensible modules such as UEFI drivers = and UEFI applications are executed. >=20 > The protocol is published immediately after signaling of the End of = DXE Event. >=20 > PI modules that need to lock or protect their resources in = anticipation of the invocation of 3rd party extensible modules should = register for notification on installation of this protocol and effect = the appropriate protections in their notification handlers. For example, = PI platform code may choose to use notification handler to lock MM by = invoking EFI_MM_ACCESS_PROTOCOL.Lock() function.=E2=80=9D >=20 > =20 >=20 > =20 >=20 > SMM environment is a *runtime* environment. SMRAM will be even changed = after SmmReadyToLock, for example, by SMM handler for SMM communication = from DXE. >=20 > =20 >=20 > =20 >=20 > Thanks, >=20 > Star >=20 > From: Abhishek Singh [mailto:abh@cs.unc.edu ]=20= > Sent: Tuesday, May 29, 2018 2:02 AM > To: Marvin H=C3=A4user > > Cc: edk2-devel@lists.01.org ; Laszlo = Ersek >; afish@apple.com = ; Ni, Ruiyu >; Dong, Eric >; Zeng, Star > > Subject: Re: [edk2] smm lock query >=20 > =20 >=20 > Thank you everyone for your inputs and clarifications. They are = helping me to better understand the uefi code, to which I am very new. I = do not mean to hijack the thread: so please continue your discussions = about whether the implementation matches the spec. >=20 > =20 >=20 > However, I want to state why I am interested in the IPL code. For my = research, I wish to dump the contents of SMRAM when it has reached = steady state, i.e., all the drivers have made changes to smram and it = has been locked. The current implementation (smm ipl) locks smram when = it receives the SmmReadyToLock event and then propagates the event to = the smm drivers that make further changes to smram. Unfortunately, I = cannot take a snapshot of smram after it has been locked! Thus, I have = solved this issue by propagating the event to the smm drivers first = (using SmmIplGuidedEventNotify), then opening access to and dumping the = contents of SMRAM, and finally closing access to and locking smram. = Would it be fair to say that this would give me the fully initialized = contents of smram? >=20 > =20 >=20 > =20 >=20 > =20 >=20 > My second observation is that despite opening access to smram, I am = unable to access its contents, which is a violation of the = EFI_MM_ACCESS_PROTOCOL.Open() description in the spec, which says: "This = function =E2=80=9Copens=E2=80=9D MMRAM so that it is visible while not = inside of MM." Note that I am working with minnowboard firmware release = 0.97. So some of the binaries like SmmAccess.efi are provided by Intel, = while others have been built from the edk source tree: thus, this may = not be an EDK issue. Please suggest further steps and/or workarounds. = Should I contact edk2-platforms maintainers, or start a new thread here = for this issue? >=20 > =20 >=20 > -Abhishek >=20 > =20 >=20 > =20 >=20 > On Mon, May 28, 2018 at 10:03 AM, Marvin H=C3=A4user = > wrote: >=20 > Hello Andrew and Laszlo, >=20 > Thanks for your comments! > Of course I'm with you that it is the platform that signals the = SmmReadyToLock event and therefor is aware. > However, they might rely on the protocol's description that the = resources are about(!) to be locked and code accordingly, not = considering the event characteristic of the handler in PiSmmIpl. > The code might be written by different people, not especially reviewed = against edk2's actions, or additional code might be supplied by third = parties that do not have tree code access (which, by integration, would = be "platform binaries" by the definition applying here). >=20 > Therefor I would still ask everyone to consider figuring out a = solution to this discrepancy from the specification, such as the = internal "dummy event" I proposed. >=20 > Thanks, > Marvin. >=20 >=20 > > -----Original Message----- > > From: Laszlo Ersek > > > Sent: Monday, May 28, 2018 12:58 PM > > 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 = > > Subject: Re: [edk2] smm lock query > >=20 > > 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. > >=20 > > 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). > >=20 > > Thanks > > Laszlo >=20 > =20 >=20 >=20