From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CBF141A1E91 for ; Tue, 11 Oct 2016 09:37:24 -0700 (PDT) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP; 11 Oct 2016 09:37:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,329,1473145200"; d="scan'208";a="18959022" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga004.jf.intel.com with ESMTP; 11 Oct 2016 09:37:24 -0700 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 11 Oct 2016 09:37:24 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX155.amr.corp.intel.com ([10.22.240.21]) with mapi id 14.03.0248.002; Tue, 11 Oct 2016 09:37:23 -0700 From: "Kinney, Michael D" To: "Cohen, Eugene" , "Gao, Liming" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" , "Kinney, Michael D" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2HcgAPkDOAAASYTYAAAl4ugAAJFCIAAZowooAATr0ZgAAN5a1Q//+ha4CAAF3c4P//4cCAgABuoWCAANGyAIAAY+Jw Date: Tue, 11 Oct 2016 16:37:22 +0000 Message-ID: References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> <654a587b-8f79-51ef-8ba9-a29779de46c9@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B4820B6@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTg0ZmM5NWItYTY2Mi00MjI0LWI5OWYtMzFkZjZiNTZhODQ1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlVhdVNkbzN5YjB4Yms2RTFhS3ZORGRhZTc2WEJEVFV1d1EwMFFhcHgwdTA9In0= x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:37:25 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Co= hen, Eugene > Sent: Tuesday, October 11, 2016 8:18 AM > To: Kinney, Michael D ; Gao, Liming ; > Laszlo Ersek ; edk2-devel@lists.01.org ; > Yao, Jiewen ; Andrew Fish (afish@apple.com) > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle Services >=20 > Mike, >=20 > > I agree that accessing DXE protocols in an SMI handler is not allowed. > > > > It is legal for an SMM Driver to access DXE content in the SMM Driver E= ntry Point. >=20 > To digress from the original thread a bit.. >=20 > There's legal from a PI perspective but for the situations that warrant s= tricter > security where this would not be (execution of non-SMM code inside SMM). = I think it > would be useful to come up with terminology so we know what model we're t= alking about. > I can envision four different SMM models: >=20 > 1. Framework 0.9 SMM - dual DXE/SMM drivers > 2. PI SMM (pre-1.5) - IPL from DXE, SMM drivers use Boot Services at init > 3. PI Standalone SMM (1.5) - IPL from SEC or PEI, SMM drivers may use Boo= t Services > when they become available > 4. PI Strict Standalone SMM (1.5) - IPL from SEC or PEI, SMM drivers neve= r use Boot > Services >=20 > So for the statement I made I'm referring to the "Strict Standalone" - as= you can > probably tell that is what I'm targeting right now. >=20 > > If you are providing an abstraction for policy data, would a PCD be a b= etter way > > to store/access that information that already works for all phases? >=20 > The policy data isn't static on some platform so the protocol provides a = good way to > evaluate the conditions at runtime. I'm sure a dynamic PCD could be used= to accomplish > this (although with the strict standalone model this would require more i= nfrastructure > to be developed) but my goal at this point is not to review the use of pr= otocols for > policies but to provide an example of a use case for the ProtocolLib prop= osal. This > was the first example I came up with but I expect there to be more functi= onal cases as > well. >=20 > Earlier in the thread you mentioned that protocol GUIDs should not be sha= red across DXE > and SMM - I didn't want to lose track of that since what I'm proposing wo= uld directly > contradict the proposal, so could you elaborate on what you were referrin= g to with that > statement? I am not aware of any in the UEFI/PI specs. Every time a new protocol is d= efined it is=20 recommended that a new GUID value be used to prevent GUID collisions. If y= ou have every had to debug a GUID collision, you know how hard that is to figure out. To ask a question from a different perspective. What is the value of using= the same GUID for a DXE protocol and SMM protocol? >=20 > Thanks, >=20 > Eugene >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Monday, October 10, 2016 2:40 PM > To: Cohen, Eugene ; Gao, Liming ; La= szlo Ersek > ; edk2-devel@lists.01.org ; Ya= o, Jiewen > ; Andrew Fish (afish@apple.com) ; = Kinney, > Michael D > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle Services >=20 > Eugene, >=20 > I agree that accessing DXE protocols in an SMI handler is not allowed. >=20 > It is legal for an SMM Driver to access DXE content in the SMM Driver Ent= ry Point. >=20 > For example, if an SMM Driver depends on PCDs, the PCD values can be read= from the > PCD database through the PCD Protocol in the driver entry point. >=20 > If you are providing an abstraction for policy data, would a PCD be a bet= ter way > to store/access that information that already works for all phases? >=20 > Thanks, >=20 > Mike >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Cohen, Eugene > > Sent: Monday, October 10, 2016 1:11 PM > > To: Kinney, Michael D ; Gao, Liming > > ; Laszlo Ersek ; edk2-devel@li= sts.01.org > > ; Yao, Jiewen ; Andrew Fi= sh > > (afish@apple.com) > > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and= Handle > > Services > > > > Mike, > > > > > Can you provide examples in EDK II today where the same GUID Value > > > and Structure definition > > > are used in both the UEFI Handle Database and the SMM Handle > > > Database. > > > > The example exists in our internal code right now. We have two platfor= m families: > > one with SMM and one without. We have a library, originally developed = as a DXE > > library, that use a protocol to determine a secure boot policy setting.= This library > > is linked against our variable driver. In our non-SMM system the varia= ble driver > > runs as a Runtime DXE component and the policy protocol referenced is p= ublished in > > the Boot Services protocol DB. In our SMM system the variable driver r= uns in SMM and > > the policy protocol is published in the SMM protocol DB. The protocol = is identical > > and uses the same GUID. So in this scenario we don't install the proto= col > > simultaneously in both environments, rather we have different platforms= where the > > protocol resides on one side or the other. Since this protocol is real= ly simple > > (it's not using events, TPL or depending on UEFI boot services stuff) i= t works well > > for this model. > > > > > I am aware of cases where an SMM Driver looks for protocols in the > > > DXE Handle database, > > > but I don't think your proposed lib would cover that case. > > > > Correct - in our usage we are trying to discourage the cross-pollinatio= n of SMM and > > DXE in this way since security minded people get nervous when SMM execu= tes outside of > > the secure sandbox. > > > > Thanks, > > > > Eugene > > _______________________________________________ > > 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