From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 407D41A1E3B for ; Mon, 10 Oct 2016 13:39:46 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 10 Oct 2016 13:39:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,474,1473145200"; d="scan'208";a="1068625883" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga002.fm.intel.com with ESMTP; 10 Oct 2016 13:39:46 -0700 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 10 Oct 2016 13:39:44 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX111.amr.corp.intel.com ([169.254.12.152]) with mapi id 14.03.0248.002; Mon, 10 Oct 2016 13:39:43 -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//4cCAgABuoWA= Date: Mon, 10 Oct 2016 20:39:43 +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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDVhNTU5MTEtNzVmMy00ZjFmLTk1MTEtMGY0YjY5YjgwMjM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ind6QzVKTUt2SlFFY2NTNmliK1pnM252Smt1cmtIaWhzUHhXK2sxSlR2RGs9In0= x-originating-ip: [10.22.254.138] 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: Mon, 10 Oct 2016 20:39:46 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, 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 Entry= Point. For example, if an SMM Driver depends on PCDs, the PCD values can be read f= rom the=20 PCD database through the PCD Protocol in the driver entry point. If you are providing an abstraction for policy data, would a PCD be a bette= r way=20 to store/access that information that already works for all phases? Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Co= hen, Eugene > Sent: Monday, October 10, 2016 1:11 PM > To: Kinney, Michael D ; Gao, Liming > ; Laszlo Ersek ; edk2-devel@list= s.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 > > 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. >=20 > The example exists in our internal code right now. We have two platform = 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 variabl= e driver > runs as a Runtime DXE component and the policy protocol referenced is pub= lished in > the Boot Services protocol DB. In our SMM system the variable driver run= s 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 protoco= l > simultaneously in both environments, rather we have different platforms w= here the > protocol resides on one side or the other. Since this protocol is really= simple > (it's not using events, TPL or depending on UEFI boot services stuff) it = works well > for this model. >=20 > > 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. >=20 > Correct - in our usage we are trying to discourage the cross-pollination = of SMM and > DXE in this way since security minded people get nervous when SMM execute= s outside of > the secure sandbox. >=20 > Thanks, >=20 > Eugene > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel