Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

["Kinney, Michael D" <michael.d.kinney@intel.com>]

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Tuesday, October 11, 2016 8:18 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>;
> Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>;
> Yao, Jiewen <jiewen.yao@intel.com>; Andrew Fish (afish@apple.com) <afish@apple.com>
> 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:michael.d.kinney@intel.com]
> Sent: Monday, October 10, 2016 2:40 PM
> To: Cohen, Eugene <eugene@hp.com>; Gao, Liming <liming.gao@intel.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Yao, Jiewen
> <jiewen.yao@intel.com>; Andrew Fish (afish@apple.com) <afish@apple.com>; Kinney,
> Michael D <michael.d.kinney@intel.com>
> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> > Sent: Monday, October 10, 2016 1:11 PM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > <liming.gao@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
> > <edk2-devel@ml01.01.org>; Yao, Jiewen <jiewen.yao@intel.com>; Andrew Fish
> > (afish@apple.com) <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 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
> > 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