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

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

[Cohen, Eugene]

Request for Comments...

Both UEFI/DXE and SMM support the protocol / handle database concept.  Some protocol definitions are able used in both environments with different implementations behind them.

We'd like to create a library that could be used in either DXE or SMM making use of protocol and handle services.  For example, we'd like to be able to do a LocateProtocol for a certain protocol and make use of the protocol regardless of the environment we're executing in.

In order to create a neutral API for protocol and handle services from either environment, I'm proposing that we create a "ProtocolLib" that abstracts protocol install, uninstall, HandleProtocol, install notification, LocateHandle and LocateProtocol implementations - basically all the protocol and handle services common across UEFI Boot Services and SMST.   A DXE instance of ProtocolLib would direct functions through the Boot Services table and an SMM instance of ProtocolLib would go through the SMST.   (We also would like to maintain separation between DXE and SMM in support of the PI 1.5 Standalone SMM model which is easy to achieve with separate library instances.)

We have a similar model already with the MemoryAllocationLib so this would follow in its footsteps.


Please share your thoughts...

Eugene

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

[Laszlo Ersek]

On 09/30/16 16:13, Cohen, Eugene wrote:
> Request for Comments...
> 
> Both UEFI/DXE and SMM support the protocol / handle database concept.
> Some protocol definitions are able used in both environments with
> different implementations behind them.
> 
> We'd like to create a library that could be used in either DXE or SMM
> making use of protocol and handle services.  For example, we'd like
> to be able to do a LocateProtocol for a certain protocol and make use
> of the protocol regardless of the environment we're executing in.
> 
> In order to create a neutral API for protocol and handle services
> from either environment, I'm proposing that we create a "ProtocolLib"
> that abstracts protocol install, uninstall, HandleProtocol, install
> notification, LocateHandle and LocateProtocol implementations -
> basically all the protocol and handle services common across UEFI
> Boot Services and SMST.   A DXE instance of ProtocolLib would direct
> functions through the Boot Services table and an SMM instance of
> ProtocolLib would go through the SMST.   (We also would like to
> maintain separation between DXE and SMM in support of the PI 1.5
> Standalone SMM model which is easy to achieve with separate library
> instances.)
> 
> We have a similar model already with the MemoryAllocationLib so this
> would follow in its footsteps.
> 
> 
> Please share your thoughts...

As far as I know:
- the DXE and SMM protocol databases are distinct,
- the same protocol GUID may or may not be installed (on one or more)
handle(s) in either,
- even if a protocol GUID exists uniquely in exactly one of those
databases, the locator function would have to return which database the
GUID was found.

My point is that every wrapper function that returns a protocol
interface (or several protocol interfaces), or handles, each such return
value will likely have to be qualified with the database where it was found.

(This is not meant as an argument against the library, just a remark
about the proposed APIs, as I see them.)

Thanks
Laszlo

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

[Cohen, Eugene]

Laszlo,

> As far as I know:
> - the DXE and SMM protocol databases are distinct,
> - the same protocol GUID may or may not be installed (on one or more)
> handle(s) in either,
> - even if a protocol GUID exists uniquely in exactly one of those databases,
> the locator function would have to return which database the GUID was
> found.
> 
> My point is that every wrapper function that returns a protocol interface (or
> several protocol interfaces), or handles, each such return value will likely
> have to be qualified with the database where it was found.

The intent here is to only search the UEFI DB from a DXE/UEFI driver and the SMM DB from an SMM driver and not to cross between.  So which protocol DB is searched is purely a function of the module type (i.e. what instance of the ProtocolLib it was linked against).  This is analogous to what is done with MemoryAllocationLib which either allocates from the UEFI memory pools for UEFI/DXE modules (UefiMemoryAllocationLib instance) or from the SMM memory pools for SMM modules (SmmMemoryAllocationLib).

Sorry I wasn't more clear initially.

Eugene

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

[Tim Lewis]

Eugene --

Since SMM drivers today are actually DXE drivers during the initialization phase, are you going to (a) have your library check InSmm? or (b) only work with pure SMM stand-alone drivers?

Thanks,

Tim

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: Friday, September 30, 2016 9:37 AM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; 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

Laszlo,

> As far as I know:
> - the DXE and SMM protocol databases are distinct,
> - the same protocol GUID may or may not be installed (on one or more)
> handle(s) in either,
> - even if a protocol GUID exists uniquely in exactly one of those 
> databases, the locator function would have to return which database 
> the GUID was found.
> 
> My point is that every wrapper function that returns a protocol 
> interface (or several protocol interfaces), or handles, each such 
> return value will likely have to be qualified with the database where it was found.

The intent here is to only search the UEFI DB from a DXE/UEFI driver and the SMM DB from an SMM driver and not to cross between.  So which protocol DB is searched is purely a function of the module type (i.e. what instance of the ProtocolLib it was linked against).  This is analogous to what is done with MemoryAllocationLib which either allocates from the UEFI memory pools for UEFI/DXE modules (UefiMemoryAllocationLib instance) or from the SMM memory pools for SMM modules (SmmMemoryAllocationLib).

Sorry I wasn't more clear initially.

Eugene
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Cohen, Eugene]

Tim,

My focus at the moment is on standalone SMM drivers, but in order to support the dual-mode DXE_SMM_DRIVER modules we could have another instance that does the InSmm check at runtime.

Eugene

> -----Original Message-----
> From: Tim Lewis [mailto:tim.lewis@insyde.com]
> Sent: Friday, September 30, 2016 10:41 AM
> To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-
> devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Eugene --
> 
> Since SMM drivers today are actually DXE drivers during the
> initialization phase, are you going to (a) have your library check
> InSmm? or (b) only work with pure SMM stand-alone drivers?
> 
> Thanks,
> 
> Tim
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> Of Cohen, Eugene
> Sent: Friday, September 30, 2016 9:37 AM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
> <edk2-devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Laszlo,
> 
> > As far as I know:
> > - the DXE and SMM protocol databases are distinct,
> > - the same protocol GUID may or may not be installed (on one or
> more)
> > handle(s) in either,
> > - even if a protocol GUID exists uniquely in exactly one of those
> > databases, the locator function would have to return which database
> > the GUID was found.
> >
> > My point is that every wrapper function that returns a protocol
> > interface (or several protocol interfaces), or handles, each such
> > return value will likely have to be qualified with the database where
> it was found.
> 
> The intent here is to only search the UEFI DB from a DXE/UEFI driver
> and the SMM DB from an SMM driver and not to cross between.  So
> which protocol DB is searched is purely a function of the module type
> (i.e. what instance of the ProtocolLib it was linked against).  This is
> analogous to what is done with MemoryAllocationLib which either
> allocates from the UEFI memory pools for UEFI/DXE modules
> (UefiMemoryAllocationLib instance) or from the SMM memory pools
> for SMM modules (SmmMemoryAllocationLib).
> 
> Sorry I wasn't more clear initially.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[Tim Lewis]

Eugene --

Since the standalone file type isn't yet in the EDK2 code, the build system will not be able to make this distinction in the library's INF file. 

Tim


-----Original Message-----
From: Cohen, Eugene [mailto:eugene@hp.com] 
Sent: Friday, September 30, 2016 9:51 AM
To: Tim Lewis <tim.lewis@insyde.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; 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

Tim,

My focus at the moment is on standalone SMM drivers, but in order to support the dual-mode DXE_SMM_DRIVER modules we could have another instance that does the InSmm check at runtime.

Eugene

> -----Original Message-----
> From: Tim Lewis [mailto:tim.lewis@insyde.com]
> Sent: Friday, September 30, 2016 10:41 AM
> To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek <lersek@redhat.com>; 
> edk2-devel@lists.01.org <edk2- devel@ml01.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; 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
> 
> Eugene --
> 
> Since SMM drivers today are actually DXE drivers during the 
> initialization phase, are you going to (a) have your library check 
> InSmm? or (b) only work with pure SMM stand-alone drivers?
> 
> Thanks,
> 
> Tim
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 
> Cohen, Eugene
> Sent: Friday, September 30, 2016 9:37 AM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org 
> <edk2-devel@ml01.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; 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
> 
> Laszlo,
> 
> > As far as I know:
> > - the DXE and SMM protocol databases are distinct,
> > - the same protocol GUID may or may not be installed (on one or
> more)
> > handle(s) in either,
> > - even if a protocol GUID exists uniquely in exactly one of those 
> > databases, the locator function would have to return which database 
> > the GUID was found.
> >
> > My point is that every wrapper function that returns a protocol 
> > interface (or several protocol interfaces), or handles, each such 
> > return value will likely have to be qualified with the database 
> > where
> it was found.
> 
> The intent here is to only search the UEFI DB from a DXE/UEFI driver 
> and the SMM DB from an SMM driver and not to cross between.  So which 
> protocol DB is searched is purely a function of the module type (i.e. 
> what instance of the ProtocolLib it was linked against).  This is 
> analogous to what is done with MemoryAllocationLib which either 
> allocates from the UEFI memory pools for UEFI/DXE modules 
> (UefiMemoryAllocationLib instance) or from the SMM memory pools for 
> SMM modules (SmmMemoryAllocationLib).
> 
> Sorry I wasn't more clear initially.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[Cohen, Eugene]

Tim,

Agreed - When BaseTools gets the standalone support I expect us to be able to differentiate library instances.

I wanted to gather feedback now while we prototype on a branch.

Eugene

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> Of Tim Lewis
> Sent: Friday, September 30, 2016 10:56 AM
> To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-
> devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Eugene --
> 
> Since the standalone file type isn't yet in the EDK2 code, the build
> system will not be able to make this distinction in the library's INF file.
> 
> Tim
> 
> 
> -----Original Message-----
> From: Cohen, Eugene [mailto:eugene@hp.com]
> Sent: Friday, September 30, 2016 9:51 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-
> devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Tim,
> 
> My focus at the moment is on standalone SMM drivers, but in order to
> support the dual-mode DXE_SMM_DRIVER modules we could have
> another instance that does the InSmm check at runtime.
> 
> Eugene
> 
> > -----Original Message-----
> > From: Tim Lewis [mailto:tim.lewis@insyde.com]
> > Sent: Friday, September 30, 2016 10:41 AM
> > To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek
> <lersek@redhat.com>;
> > edk2-devel@lists.01.org <edk2- devel@ml01.01.org>; Kinney,
> Michael D
> > <michael.d.kinney@intel.com>; 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
> >
> > Eugene --
> >
> > Since SMM drivers today are actually DXE drivers during the
> > initialization phase, are you going to (a) have your library check
> > InSmm? or (b) only work with pure SMM stand-alone drivers?
> >
> > Thanks,
> >
> > Tim
> >
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
> Behalf Of
> > Cohen, Eugene
> > Sent: Friday, September 30, 2016 9:37 AM
> > To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
> > <edk2-devel@ml01.01.org>; Kinney, Michael D
> > <michael.d.kinney@intel.com>; 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
> >
> > Laszlo,
> >
> > > As far as I know:
> > > - the DXE and SMM protocol databases are distinct,
> > > - the same protocol GUID may or may not be installed (on one or
> > more)
> > > handle(s) in either,
> > > - even if a protocol GUID exists uniquely in exactly one of those
> > > databases, the locator function would have to return which
> database
> > > the GUID was found.
> > >
> > > My point is that every wrapper function that returns a protocol
> > > interface (or several protocol interfaces), or handles, each such
> > > return value will likely have to be qualified with the database
> > > where
> > it was found.
> >
> > The intent here is to only search the UEFI DB from a DXE/UEFI driver
> > and the SMM DB from an SMM driver and not to cross between.  So
> which
> > protocol DB is searched is purely a function of the module type (i.e.
> > what instance of the ProtocolLib it was linked against).  This is
> > analogous to what is done with MemoryAllocationLib which either
> > allocates from the UEFI memory pools for UEFI/DXE modules
> > (UefiMemoryAllocationLib instance) or from the SMM memory pools
> for
> > SMM modules (SmmMemoryAllocationLib).
> >
> > Sorry I wasn't more clear initially.
> >
> > 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

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

[Laszlo Ersek]

On 09/30/16 18:36, Cohen, Eugene wrote:
> Laszlo,
> 
>> As far as I know:
>> - the DXE and SMM protocol databases are distinct,
>> - the same protocol GUID may or may not be installed (on one or more)
>> handle(s) in either,
>> - even if a protocol GUID exists uniquely in exactly one of those databases,
>> the locator function would have to return which database the GUID was
>> found.
>>
>> My point is that every wrapper function that returns a protocol interface (or
>> several protocol interfaces), or handles, each such return value will likely
>> have to be qualified with the database where it was found.
> 
> The intent here is to only search the UEFI DB from a DXE/UEFI driver
> and the SMM DB from an SMM driver and not to cross between.  So which
> protocol DB is searched is purely a function of the module type (i.e.
> what instance of the ProtocolLib it was linked against).  This is
> analogous to what is done with MemoryAllocationLib which either
> allocates from the UEFI memory pools for UEFI/DXE modules
> (UefiMemoryAllocationLib instance) or from the SMM memory pools for
> SMM modules (SmmMemoryAllocationLib).
> 
> Sorry I wasn't more clear initially.

I believe I understood this. However, in the entry point function of an
SMM driver, it is permitted to look for, and invoke member functions of,
both SMM and DXE protocols [1]. If the library instance that is supposed
to be linked into SMM drivers is tied to the SMM protocol database
solely, then it won't be able to serve the use case when an SMM driver
looks for a DXE protocol in its entry point function.

(Note I'm not speaking about "Combination SMM/DXE Drivers", just purely
SMM drivers.)

[1] "Vol4_SMM_1_4_Errata_A.pdf", section "1.7 SMM Driver Initialization":

    During SMM Driver initialization, SMM Drivers have access to two
    sets of protocols: UEFI and SMM. UEFI protocols are those which are
    installed and discovered using the UEFI Boot Services. UEFI
    protocols can be located and used by SMM drivers only during SMM
    Initialization. SMM protocols are those which are installed and
    discovered using the System Management Services Table (SMST). SMM
    protocols can be discovered by SMM drivers during initialization
    time and accessed while inside of SMM.

    [...]

... Actually, I believe this applies even to MemoryAllocationLib. In an
SMM driver, the SMM-tailored MemoryAllocationLib instance only allocates
SMRAM, which is mostly fine. However, it is unsuitable for allocating
(for example) EfiBootServicesData type memory, even though that too is
permitted in the SMM driver's entry point function, I think. For that,
gBS->AllocatePool() or gBS->AllocatePages() have to be called explicitly.

Thanks
Laszlo

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

[Cohen, Eugene]

> I believe I understood this. However, in the entry point function of an
> SMM driver, it is permitted to look for, and invoke member functions
> of,
> both SMM and DXE protocols [1]. If the library instance that is
> supposed
> to be linked into SMM drivers is tied to the SMM protocol database
> solely, then it won't be able to serve the use case when an SMM driver
> looks for a DXE protocol in its entry point function.

Agreed - non-standalone SMM drivers (notice the new terminology I'm injecting to prepare us for PI 1.5) can peek over at UEFI/DXE.  This is not the use case I'm trying to enable here (and I would argue as an industry is a practice we will try to discourage over time).

> ... Actually, I believe this applies even to MemoryAllocationLib. In an
> SMM driver, the SMM-tailored MemoryAllocationLib instance only
> allocates
> SMRAM, which is mostly fine. However, it is unsuitable for allocating
> (for example) EfiBootServicesData type memory, even though that too
> is
> permitted in the SMM driver's entry point function, I think. For that,
> gBS->AllocatePool() or gBS->AllocatePages() have to be called
> explicitly.

Right - so the common library abstraction allocates from the "native" memory pool for the driver type and if you want something else you have to go above and beyond.  So in the spirit of that precedent I'd propose the same approach for a ProtocolLib implementation.

Thanks, great feedback.

Eugene

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

[Gao, Liming]

Eugene:
 Could this library cover PEI PPI?  LocatePpi and LocateProtocol both return VOID**. And, I think this library class will include Install, Notify and Locate APIs. Right?

typedef
EFI_STATUS
(EFIAPI *EFI_PEI_LOCATE_PPI)(
  IN CONST EFI_PEI_SERVICES            **PeiServices,
  IN CONST EFI_GUID                    *Guid,
  IN UINTN                             Instance,
  IN OUT   EFI_PEI_PPI_DESCRIPTOR      **PpiDescriptor OPTIONAL,
  IN OUT   VOID                        **Ppi
  );

typedef
EFI_STATUS
(EFIAPI *EFI_LOCATE_PROTOCOL)(
  IN  EFI_GUID  *Protocol,
  IN  VOID      *Registration, OPTIONAL
  OUT VOID      **Interface
  );

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: Saturday, October 1, 2016 6:05 AM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; 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

> I believe I understood this. However, in the entry point function of an
> SMM driver, it is permitted to look for, and invoke member functions
> of,
> both SMM and DXE protocols [1]. If the library instance that is
> supposed
> to be linked into SMM drivers is tied to the SMM protocol database
> solely, then it won't be able to serve the use case when an SMM driver
> looks for a DXE protocol in its entry point function.

Agreed - non-standalone SMM drivers (notice the new terminology I'm injecting to prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use case I'm trying to enable here (and I would argue as an industry is a practice we will try to discourage over time).

> ... Actually, I believe this applies even to MemoryAllocationLib. In an
> SMM driver, the SMM-tailored MemoryAllocationLib instance only
> allocates
> SMRAM, which is mostly fine. However, it is unsuitable for allocating
> (for example) EfiBootServicesData type memory, even though that too
> is
> permitted in the SMM driver's entry point function, I think. For that,
> gBS->AllocatePool() or gBS->AllocatePages() have to be called
> explicitly.

Right - so the common library abstraction allocates from the "native" memory pool for the driver type and if you want something else you have to go above and beyond. So in the spirit of that precedent I'd propose the same approach for a ProtocolLib implementation.

Thanks, great feedback.

Eugene
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Cohen, Eugene]

Liming,
>  Could this library cover PEI PPI?

Yes - excellent suggestion for PEI - I hadn't considered it because the use case hadn't come up for me yet.

> And, I think this library class will include Install, Notify and Locate APIs. Right?

Yes, this library class proposal incorporates all of the protocol and handle database related functionality.  Notify may be tricky since in DXE we have TPL and both PEI and SMM we have direct function callbacks but perhaps there's a way to abstract if we assume a default TPL or an alternate library API to initialize the callback TPL in advance.  (On the other hand this could introduce subtle bugs if driver developers lose sight of the TPL used for callbacks on this interface.)

Given the positive feedback the next step is to publish a proposed library header file for review.

Thanks,

Eugene

From: Gao, Liming [mailto:liming.gao@intel.com]
Sent: Saturday, October 08, 2016 7:50 PM
To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; 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

Eugene:
 Could this library cover PEI PPI?  LocatePpi and LocateProtocol both return VOID**. And, I think this library class will include Install, Notify and Locate APIs. Right?

typedef
EFI_STATUS
(EFIAPI *EFI_PEI_LOCATE_PPI)(
  IN CONST EFI_PEI_SERVICES            **PeiServices,
  IN CONST EFI_GUID                    *Guid,
  IN UINTN                             Instance,
  IN OUT   EFI_PEI_PPI_DESCRIPTOR      **PpiDescriptor OPTIONAL,
  IN OUT   VOID                        **Ppi
  );

typedef
EFI_STATUS
(EFIAPI *EFI_LOCATE_PROTOCOL)(
  IN  EFI_GUID  *Protocol,
  IN  VOID      *Registration, OPTIONAL
  OUT VOID      **Interface
  );

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: Saturday, October 1, 2016 6:05 AM
To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> <edk2-devel@ml01.01.org<mailto:edk2-devel@ml01.01.org>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Andrew Fish (afish@apple.com<mailto:afish@apple.com>) <afish@apple.com<mailto:afish@apple.com>>
Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

> I believe I understood this. However, in the entry point function of an
> SMM driver, it is permitted to look for, and invoke member functions
> of,
> both SMM and DXE protocols [1]. If the library instance that is
> supposed
> to be linked into SMM drivers is tied to the SMM protocol database
> solely, then it won't be able to serve the use case when an SMM driver
> looks for a DXE protocol in its entry point function.

Agreed - non-standalone SMM drivers (notice the new terminology I'm injecting to prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use case I'm trying to enable here (and I would argue as an industry is a practice we will try to discourage over time).

> ... Actually, I believe this applies even to MemoryAllocationLib. In an
> SMM driver, the SMM-tailored MemoryAllocationLib instance only
> allocates
> SMRAM, which is mostly fine. However, it is unsuitable for allocating
> (for example) EfiBootServicesData type memory, even though that too
> is
> permitted in the SMM driver's entry point function, I think. For that,
> gBS->AllocatePool() or gBS->AllocatePages() have to be called
> explicitly.

Right - so the common library abstraction allocates from the "native" memory pool for the driver type and if you want something else you have to go above and beyond. So in the spirit of that precedent I'd propose the same approach for a ProtocolLib implementation.

Thanks, great feedback.

Eugene
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Kinney, Michael D]

Eugene,

I am confused by one aspect of this proposal.

The GUID values for PPIs, DXE Protocols, UEFI Protocols, 
and SMM Protocols are unique.  Which means if code is written
to work in one phase, you can not share code to another 
phase because the GUID values must be changed.

The other libs you mentioned have the attribute that the 
parameters to the library APIs do not have to be updated as 
source code is moved or shared between phase types.

Given that the source can not be shared, what is gained by
adding a library?

Would you recommend using this lib in all module types?

Maybe you can share both the proposed library class APIs and
typical usage from different module types.

Mike


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Monday, October 10, 2016 8:24 AM
> To: Gao, Liming <liming.gao@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Liming,
> >  Could this library cover PEI PPI?
> 
> Yes - excellent suggestion for PEI - I hadn't considered it because the use case
> hadn't come up for me yet.
> 
> > And, I think this library class will include Install, Notify and Locate APIs.
> Right?
> 
> Yes, this library class proposal incorporates all of the protocol and handle database
> related functionality.  Notify may be tricky since in DXE we have TPL and both PEI
> and SMM we have direct function callbacks but perhaps there's a way to abstract if we
> assume a default TPL or an alternate library API to initialize the callback TPL in
> advance.  (On the other hand this could introduce subtle bugs if driver developers
> lose sight of the TPL used for callbacks on this interface.)
> 
> Given the positive feedback the next step is to publish a proposed library header
> file for review.
> 
> Thanks,
> 
> Eugene
> 
> From: Gao, Liming [mailto:liming.gao@intel.com]
> Sent: Saturday, October 08, 2016 7:50 PM
> To: Cohen, Eugene <eugene@hp.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 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
> 
> Eugene:
>  Could this library cover PEI PPI?  LocatePpi and LocateProtocol both return VOID**.
> And, I think this library class will include Install, Notify and Locate APIs. Right?
> 
> typedef
> EFI_STATUS
> (EFIAPI *EFI_PEI_LOCATE_PPI)(
>   IN CONST EFI_PEI_SERVICES            **PeiServices,
>   IN CONST EFI_GUID                    *Guid,
>   IN UINTN                             Instance,
>   IN OUT   EFI_PEI_PPI_DESCRIPTOR      **PpiDescriptor OPTIONAL,
>   IN OUT   VOID                        **Ppi
>   );
> 
> typedef
> EFI_STATUS
> (EFIAPI *EFI_LOCATE_PROTOCOL)(
>   IN  EFI_GUID  *Protocol,
>   IN  VOID      *Registration, OPTIONAL
>   OUT VOID      **Interface
>   );
> 
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Saturday, October 1, 2016 6:05 AM
> To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org> <edk2-
> devel@ml01.01.org<mailto:edk2-devel@ml01.01.org>>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Yao, Jiewen
> <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Andrew Fish
> (afish@apple.com<mailto:afish@apple.com>) <afish@apple.com<mailto:afish@apple.com>>
> Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle
> Services
> 
> > I believe I understood this. However, in the entry point function of an
> > SMM driver, it is permitted to look for, and invoke member functions
> > of,
> > both SMM and DXE protocols [1]. If the library instance that is
> > supposed
> > to be linked into SMM drivers is tied to the SMM protocol database
> > solely, then it won't be able to serve the use case when an SMM driver
> > looks for a DXE protocol in its entry point function.
> 
> Agreed - non-standalone SMM drivers (notice the new terminology I'm injecting to
> prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use case I'm trying
> to enable here (and I would argue as an industry is a practice we will try to
> discourage over time).
> 
> > ... Actually, I believe this applies even to MemoryAllocationLib. In an
> > SMM driver, the SMM-tailored MemoryAllocationLib instance only
> > allocates
> > SMRAM, which is mostly fine. However, it is unsuitable for allocating
> > (for example) EfiBootServicesData type memory, even though that too
> > is
> > permitted in the SMM driver's entry point function, I think. For that,
> > gBS->AllocatePool() or gBS->AllocatePages() have to be called
> > explicitly.
> 
> Right - so the common library abstraction allocates from the "native" memory pool for
> the driver type and if you want something else you have to go above and beyond. So in
> the spirit of that precedent I'd propose the same approach for a ProtocolLib
> implementation.
> 
> Thanks, great feedback.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto: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

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

[Cohen, Eugene]

Mike,

> The GUID values for PPIs, DXE Protocols, UEFI Protocols,
> and SMM Protocols are unique.  Which means if code is written
> to work in one phase, you can not share code to another
> phase because the GUID values must be changed.

My original use case was a protocol definition where both the protocol structure and GUID value are shared across DXE and SMM.  I was not aware of the "GUIDs must be unique" requirement - can you elaborate on this?

> The other libs you mentioned have the attribute that the
> parameters to the library APIs do not have to be updated as
> source code is moved or shared between phase types.

This API usage would have to be consistent across phases as well for this proposal to be of value.  I agree - if the users of the library have to change the way they call then the library is of little (or maybe even negative) value.

> Given that the source can not be shared, what is gained by
> adding a library?

The use case is definitely to share the source.

In our envisioned use case we would have these two stacks:

DXE Driver
Library X that uses a "protocol"
ProtocolLib (DXE instance)

and

SMM Driver
Library X that uses a "protocol"
ProtocolLib (SMM instance)

so the value is being able to reuse Library X since all it depends on is a common protocol.  The protocol would need to have absolutely identical usage (and in our use case this is true).

> Would you recommend using this lib in all module types?

I was originally envisioning only DXE and SMM Drivers (and Cores) only.  Jiewen suggested PEI which I had not considered which could theoretically be supported so long as a common "protocol" definition was usable across PEI and DXE/SMM which is a situation I have not yet had a need to explore.  (I think the semantics of the PEI no-writeable-globals due to Flash XIP drives differences in design that may make this impractical but I'm not sure.)
 
> Maybe you can share both the proposed library class APIs and
> typical usage from different module types.

Yes, I think I need to make it a little more real at this point.  Action Item Taken.

Eugene

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

[Kinney, Michael D]

Eugene,

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.

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. 

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Monday, October 10, 2016 9:23 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,
> 
> > The GUID values for PPIs, DXE Protocols, UEFI Protocols,
> > and SMM Protocols are unique.  Which means if code is written
> > to work in one phase, you can not share code to another
> > phase because the GUID values must be changed.
> 
> My original use case was a protocol definition where both the protocol structure and
> GUID value are shared across DXE and SMM.  I was not aware of the "GUIDs must be
> unique" requirement - can you elaborate on this?
> 
> > The other libs you mentioned have the attribute that the
> > parameters to the library APIs do not have to be updated as
> > source code is moved or shared between phase types.
> 
> This API usage would have to be consistent across phases as well for this proposal to
> be of value.  I agree - if the users of the library have to change the way they call
> then the library is of little (or maybe even negative) value.
> 
> > Given that the source can not be shared, what is gained by
> > adding a library?
> 
> The use case is definitely to share the source.
> 
> In our envisioned use case we would have these two stacks:
> 
> DXE Driver
> Library X that uses a "protocol"
> ProtocolLib (DXE instance)
> 
> and
> 
> SMM Driver
> Library X that uses a "protocol"
> ProtocolLib (SMM instance)
> 
> so the value is being able to reuse Library X since all it depends on is a common
> protocol.  The protocol would need to have absolutely identical usage (and in our use
> case this is true).
> 
> > Would you recommend using this lib in all module types?
> 
> I was originally envisioning only DXE and SMM Drivers (and Cores) only.  Jiewen
> suggested PEI which I had not considered which could theoretically be supported so
> long as a common "protocol" definition was usable across PEI and DXE/SMM which is a
> situation I have not yet had a need to explore.  (I think the semantics of the PEI
> no-writeable-globals due to Flash XIP drives differences in design that may make this
> impractical but I'm not sure.)
> 
> > Maybe you can share both the proposed library class APIs and
> > typical usage from different module types.
> 
> Yes, I think I need to make it a little more real at this point.  Action Item Taken.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

[Cohen, Eugene]

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

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

[Kinney, Michael D]

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

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

[Cohen, Eugene]

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

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

[Kinney, Michael D]

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