> -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of Cohen, > Eugene > Sent: Tuesday, October 11, 2016 8:18 AM > To: Kinney, Michael D <[email protected]>; Gao, Liming > <[email protected]>; > Laszlo Ersek <[email protected]>; [email protected] > <[email protected]>; > Yao, Jiewen <[email protected]>; Andrew Fish ([email protected]) > <[email protected]> > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and > Handle Services > > 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 Entry > > Point. > > To digress from the original thread a bit.. > > There's legal from a PI perspective but for the situations that warrant > stricter > 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 > 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 you > 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 > > better way > > 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 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 > infrastructure > to be developed) but my goal at this point is not to review the use of > protocols for > policies but to provide an example of a use case for the ProtocolLib > proposal. This > was the first example 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 shared > across DXE > and SMM - I didn't want to lose track of that since what I'm proposing would > directly > contradict the proposal, so could you elaborate on what you were referring to > with that > statement?
I am not aware of any in the UEFI/PI specs. Every time a new protocol is defined it is recommended that a new GUID value be used to prevent GUID collisions. If you 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? > > Thanks, > > Eugene > > -----Original Message----- > From: Kinney, Michael D [mailto:[email protected]] > Sent: Monday, October 10, 2016 2:40 PM > To: Cohen, Eugene <[email protected]>; Gao, Liming <[email protected]>; Laszlo > Ersek > <[email protected]>; [email protected] <[email protected]>; Yao, > Jiewen > <[email protected]>; Andrew Fish ([email protected]) <[email protected]>; > Kinney, > Michael D <[email protected]> > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and > Handle 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 > from the > 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 better > way > to store/access that information that already works for all phases? > > Thanks, > > Mike > > > -----Original Message----- > > From: edk2-devel [mailto:[email protected]] On Behalf Of > > Cohen, Eugene > > Sent: Monday, October 10, 2016 1:11 PM > > To: Kinney, Michael D <[email protected]>; Gao, Liming > > <[email protected]>; Laszlo Ersek <[email protected]>; > > [email protected] > > <[email protected]>; Yao, Jiewen <[email protected]>; Andrew Fish > > ([email protected]) <[email protected]> > > 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 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 variable > > driver > > runs as a Runtime DXE component and the policy protocol referenced is > > published in > > the Boot Services protocol DB. In our SMM system the variable driver runs > > 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 protocol > > simultaneously in both environments, rather we have different platforms > > where 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. > > > > > 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-pollination of > > SMM and > > DXE in this way since security minded people get nervous when SMM executes > > outside of > > the secure sandbox. > > > > Thanks, > > > > Eugene > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
