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.29; helo=mail-in7.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 D213720971741 for ; Sun, 27 May 2018 13:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527453922; x=2391367522; 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=wYJcXZ3+UB9aPGkABJHJg0PClX4MmbyUb/GviL88Z6M=; b=i17cP14k7wM7+tsC9iUwXErrUpB9NA/pwqp50PegqogT2uuEf9tzEAw5YlOQmoXZ +1Y5A661l+7GnSoSm2BCFdrDRwe/hRBq4w+u0C+eIEBwfsItHQgXQ3rEvMs5spFg pVQUHKRuK1dUFmFwWxmKxc3DhRDF5Arp/5z2hOia7vcc7sYVwi8S6d9qXpi2VpZ3 IWMiVq8p7ounG1KpVSnZ0DN0i2TtLIR1Q6SwP2nmkJ6P7x982D58mtkm25g7aRNd XClk5mLMJOf/YY+7T7ySecGhqUhPA3UqBbuAVBDi2pAioxgoET2Y5MiqYJ2Wg4Tm rNZ9jYeviv+SOaR/tZ2p4A==; X-AuditID: 11973e16-f35ff7000000132c-9c-5b0b18e13d10 Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 99.C2.04908.2E81B0B5; Sun, 27 May 2018 13:45:22 -0700 (PDT) MIME-version: 1.0 Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9E001SOMZLOB50@ma1-mtap-s01.corp.apple.com>; Sun, 27 May 2018 13:45:21 -0700 (PDT) Received: from [17.234.177.43] (unknown [17.234.177.43]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9E00IZTMZITN10@ma1-mmpp-sz10.apple.com>; Sun, 27 May 2018 13:45:21 -0700 (PDT) X-Va-A: X-Va-T-CD: 1aca8e1c60e7b90bb50f7ec4cabe7d31 X-Va-E-CD: 180a5a6e85d6c831d5b48afa05384183 X-Va-R-CD: 4bb4db1280b847e4cbdc5a90350b1a38 X-Va-CD: 0 X-Va-ID: 075f9c87-5088-43e8-9f46-a3705ee86004 X-V-A: X-V-T-CD: 4a30a624aacf26b334adcf21321ddbc3 X-V-E-CD: 180a5a6e85d6c831d5b48afa05384183 X-V-R-CD: 4bb4db1280b847e4cbdc5a90350b1a38 X-V-CD: 0 X-V-ID: 3fa96208-39b9-4d46-af4a-292cf2256dd9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-27_11:,, signatures=0 Sender: afish@apple.com From: Andrew Fish Message-id: <4FA35A98-2E2F-4C3F-B148-4B058C3C14B5@apple.com> Date: Sun, 27 May 2018 13:45:17 -0700 In-reply-to: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> Cc: "ruiyu.ni@intel.com" , "eric.dong@intel.com" , "edk2-devel@lists.01.org" , Laszlo Ersek , "star.zeng@intel.com" To: Marvin H?user References: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUiqOHDqvtIgjvaYMZ5DYs9h44yW2x+EWyx 7NgOFou3/6+yW7zsWc1usa/X2oHNY/Gel0we3bP/sXhsfv2C2eP9vqtsASxRXDYpqTmZZalF +nYJXBlHfkkUvF3DWHHn+RzWBsa7Uxm7GDk5JARMJHZv+c3axcjFISSwj0ni4NabzCAJXgFB iR+T77GA2MwCYRL3T/5kgijayCSxc/dXFghnIpPExku3oEaxS/z5tYMFwtaW2HKpgwnGXr58 FhuM/XPXdHYIm0tiwdbTrBC2rsTsr5OZIWw2ifUnlkD1aknM2HyKEcZ+e+kmG4zdueUtVC+n xPkvE6Fm6kg8vnYcys6W2LR5BViNsIC4xLszm8DmswkoS6yY/4Ed4ksbiX3vFzJC1ChJXDn+ DMxmEVCVuHvpJ5jNKWAr8fr8eXaQh5kFnjBKvJizCOw4EQE9iWVP30FD4g6jRMepbqjvlST+ 7zrCPIFRdhZSUM5CCkoIW0vi+6NWoDgHkC0vcfC8LERYU+LZvU/sELa2xJN3F1gXMLKtYhTK TczM0c3MM9dLLCjISdVLzs/dxAhKKNPtxHYwPlxldYhRgINRiYdX4ydXtBBrYllxZe4hRmkO FiVx3urJHNFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGItj1id+DHnRy/6BZ/NSpnfNE3MC J/Xe3aby6d4soZ/18WoXbwdvEBOUeafoHl9x7MYUDp89ouJ8Nqr2wvv+X/+w5tE53SjWV8EH lA81B95qOBGUaxAUwy2VfvnRZN3nERNW7Zw8ZTXLnQDJKU8SZjz1C58onhbwZgr3rf9s+WGr I3+yrewJy1RiKc5INNRiLipOBACQ49rpCQMAAA== 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: Sun, 27 May 2018 20:45:24 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On May 27, 2018, at 1:44 PM, 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. > > We probably need to reread the PI spec and make sure the spec is following the letter of the law, but I'd guess locking earlier is likely OK. > Sorry I meant edk2, not spec, following the letter of the law. Thanks, Andrew Fish > Thanks, > > Andrew Fish > >> Thanks and regards, >> Marvin >> >>> -----Original Message----- >>> From: edk2-devel On Behalf Of >>> Abhishek Singh >>> Sent: Saturday, May 26, 2018 5:05 PM >>> To: edk2-devel@lists.01.org >>> Subject: [edk2] smm lock query >>> >>> Hi, >>> >>> This is the first time I am mailing to this list. If this is not the right place for the >>> kind of questions I am asking please let me know where to direct my queries. >>> >>> I have been looking at the SMM IPL code and a portion of the code is a little >>> confusing to me. In the function SmmIplReadyToLockEventNotify, smram is >>> locked (mSmmAccess->Lock) before the ready to lock notifications are sent >>> through SmmIplGuidedEventNotify. Shouldn't the lock be placed after the >>> ready to lock notifications? >>> >>> Best regards, >>> Abhishek >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel