From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4E6011A1E05 for ; Tue, 11 Oct 2016 08:17:38 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0292.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 11 Oct 2016 15:17:36 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0659.020; Tue, 11 Oct 2016 15:17:36 +0000 From: "Cohen, Eugene" To: "Kinney, Michael D" , "Gao, Liming" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2HcgAA5RyAAARYvtAAAp28gAAI576gAZpdBoAATn70sAABT7uAAACv6eAAA1eMgAAEjzQAAAFeCYAAJpB50A== Date: Tue, 11 Oct 2016 15:17:36 +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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.252.13] x-ms-office365-filtering-correlation-id: 1ca24e85-faf9-4f58-2d54-08d3f1e9bb63 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0292; 6:22JMr+oV4QplLFg8jdpNS9e5qPKuh5OCMaN0oo22wOovAt0j3cFKm/RU+rxkDdkHblwyBg1zIGtyfv70j/nGFJGEsGQmChKCpukwJ7yQdxJqb84S5VeGrjaXdnzzAUDNouDubJabHbqdaQB+ozan5Gtz5Wb+lvk3KM6f6uLRDd9B1OTXANSuFcHLgFjgx6wtUMETsTrUwtYgS4SDLdZeBDVN02cDTC/XNii5rt3fdeGrHzutVnCYsspMcWq1KlP0GWSwXU4uk5dfnp4mQ4Kt1H+aVkKKxJ1t/J6sfWT+MHKoQwDpsagFG/kc5JiDU9dD; 5:n7Kel3scLmacYSeGQ6HXA4XjTppxHr9uobLRjbdPvwZIMHHkfYxlozsutJPF12mApGi5EAGDzyVrAcZ3pMrGqlrOI5bIppdOhn61mQNBY7oQIU/7eFAHLE/zefrEyFShxfzbSWkt70QKGWXPp5D+Ig==; 24:0AaTlz96kfgdvb/hiAH4sI2jHwQvmYsnwRWeBALa1B/8WlE8BQhMFWOr6rLq6F0B4Fn//oD1TQ1gBSkXZTk/hBRVBKhb8O+i2i/xeklhGJw=; 7:/cxvbXDlExRKJ8TfyvJ7BZDCDL2AEcnMPHwIcl27WKmdb4vmQxl9PbWzuHO1RX4n2Mog781f7e6BTBMOv8PlDb2f4Ch3C3veZ+AKgS/YxmcTkrwrTkhTnwqEUr9WYdyQ5DZiTITxeLYOMnPQnZG8T8IHyJBU7wNgDO7usEc7ts78W1ipWJDlkSJ6PzTCv0nrEcEky4luuafFoELtB44Nk18p0W+s1ThyNFZghWBu2/J+tCaEzy0a4KqHtTRjaXwkxgLNcFIlLo+Zj6jvZYa7DzqUk3XOME/VsY77yq/cQ2j8ppNlHMWZI12Denxu4JQqHDYXtZsKV/vuEN2ayguhfJ7ob16ap+h4ckXa6zQYUQk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(162533806227266)(31960201722614)(228905959029699)(73583498263828)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AT5PR84MB0292; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0292; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(6602003)(377454003)(189002)(13464003)(189998001)(2906002)(107886002)(92566002)(50986999)(19580405001)(76176999)(2900100001)(54356999)(19580395003)(66066001)(8666005)(77096005)(15975445007)(2950100002)(3280700002)(99286002)(561944003)(105586002)(5001770100001)(5660300001)(10400500002)(106356001)(101416001)(33656002)(93886004)(7696004)(97736004)(9686002)(3660700001)(11100500001)(5002640100001)(586003)(7846002)(81166006)(81156014)(122556002)(8676002)(74316002)(87936001)(68736007)(305945005)(8936002)(7736002)(6116002)(3846002)(86362001)(102836003)(7059030)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0292; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 15:17:36.0833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0292 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 15:17:38 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mike, > 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 Ent= ry Point. To digress from the original thread a bit.. There's legal from a PI perspective but for the situations that warrant str= icter security where this would not be (execution of non-SMM code inside SM= M). I think it would be useful to come up with terminology so we know what= model we're talking about. I can envision four different SMM models: 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 Boot = Services when they become available 4. PI Strict Standalone SMM (1.5) - IPL from SEC or PEI, SMM drivers never = use Boot Services So for the statement I made I'm referring to the "Strict Standalone" - as y= ou can probably tell that is what I'm targeting right now. > If you are providing an abstraction for policy data, would a PCD be a bet= ter way=20 > to store/access that information that already works for all phases? The policy data isn't static on some platform so the protocol provides a go= od 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 infrastructure to be developed) but my goal at this poi= nt is not to review the use of protocols for policies but to provide an exa= mple of a use case for the ProtocolLib proposal. This was the first exampl= e I came up with but I expect there to be more functional cases as well. Earlier in the thread you mentioned that protocol GUIDs should not be share= d across DXE and SMM - I didn't want to lose track of that since what I'm p= roposing would directly contradict the proposal, so could you elaborate on = what you were referring to with that statement? Thanks, Eugene -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]=20 Sent: Monday, October 10, 2016 2:40 PM To: Cohen, Eugene ; Gao, Liming ; Lasz= lo Ersek ; edk2-devel@lists.01.org ; Yao, Jiewen ; Andrew Fish (afish@apple.com) ; Kinney, Michael D Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Han= dle Services 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