From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (SPF Permanent Error: Void lookup limit of 2 exceeded) identity=mailfrom; client-ip=2607:f8b0:4003:c0f::22f; helo=mail-ot0-x22f.google.com; envelope-from=abh@cs.unc.edu; receiver=edk2-devel@lists.01.org Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0801020965DF0 for ; Mon, 28 May 2018 11:02:08 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id n3-v6so14265927ota.5 for ; Mon, 28 May 2018 11:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs-unc-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0vBRGe8PnQcJ2e4jW+AKCctrkPC2MyXpmuHQhNE3XzY=; b=UW6BdAWTwQ4Z8vQmNXysVo4JZ80g0fSdVVS6i75xpejGI5mvAYzwaE43ps0vWtHcQQ 70PmxflixLoGlHUIksGZEhkMgT89iniC2H2czqqYMyUJHAxoBVnpk4cRbBewDN+pGXCK Ahpf5SGxMRa1akWUHOl3saw3gaaJgkS7zTtjDagaI7nJ2KdbXNI26ZjFFMIw56ncK89O E6ZK8HuOi/JbNBZLzuCNzB+Xni0ug9+eW/Ngcd5AjVL0h7VSubc0B/JsdsuDvH02zxEn c6oD6VXPRijLR1o1IuJG8Ddlfz9uhgg4KgogsBdbisQaObmDM9H6iyzMM/x8uVTDa1ff stWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0vBRGe8PnQcJ2e4jW+AKCctrkPC2MyXpmuHQhNE3XzY=; b=FNeh/NKgenvdIEbx/JwLNi3uO2FB1tJg2IFytZiANJtdoagBOakUdPLDKZJa6LQq8J 7DASJFL5xqyvwirvViuSFvhq+2n6MJH3ouG4cw2x2bZMy7dG3mmxMGAoAr+cpdUfituf MIfQguVyUfHkpLRpTr6EHysdkmTT1HRyEIaSiHf2KR+1VpQszxW1vAiMZpr2Fs81rJeJ iEwdICPwrsMdOXZRGgvGp3cdyiv/ErKLbToTOw1GnbSaHfMtEYSSfizGNxoK7PiTElA9 42QSA1+OdgBO+0LH4atcNA3jYXdAlkuRfE+Xad99AxiCS6o2mqgO05OQVKyq2GclUYbw p/ZA== X-Gm-Message-State: ALKqPwewRWFNh78MM3gvE70ZWACoYyk3BQ/RFsP39UZZhdC/w12Gh/4j qitafoJoPALn9AfVxIvWPnEW1VqMC/TKzIGYcCmAXg== X-Google-Smtp-Source: ADUXVKKR2n6GyoO5ZWqTXG33OrlcqBq2F3TejoWSPobsX/Bjlx25huI7bnQdWbDKsmMFkk1BmU5LXz8oFWJbVC7IAlo= X-Received: by 2002:a9d:1869:: with SMTP id t38-v6mr9744863ott.134.1527530528166; Mon, 28 May 2018 11:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2a34:0:0:0:0:0 with HTTP; Mon, 28 May 2018 11:02:07 -0700 (PDT) In-Reply-To: References: <0C4E04D0-E863-4779-AFFA-44A0E6F8FB20@apple.com> <0b422b9a-6995-896d-4166-cd9792e818de@redhat.com> From: Abhishek Singh Date: Mon, 28 May 2018 14:02:07 -0400 Message-ID: To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , "afish@apple.com" , "ruiyu.ni@intel.com" , "eric.dong@intel.com" , "star.zeng@intel.com" 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: Mon, 28 May 2018 18:02:10 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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? 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 insi= de 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? -Abhishek On Mon, May 28, 2018 at 10:03 AM, Marvin H=C3=A4user wrote: > Hello Andrew and Laszlo, > > 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 b= e > "platform binaries" by the definition applying here). > > Therefor I would still ask everyone to consider figuring out a solution t= o > this discrepancy from the specification, such as the internal "dummy even= t" > I proposed. > > Thanks, > Marvin. > > > -----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 > > > > 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 aspe= ct > > (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 ca= n > 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, whi= ch > > 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 goin= g > > to lock MM. In a practical sense any MM module that had a depex evaluat= e > > 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 >