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

Reply via email to