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? 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
