Regarding UefiDriverEntryPoint unload handler

Regarding UefiDriverEntryPoint unload handler

[Marvin H?user]

Dear developers,

While performing some research tasks, I noticed that when UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD entries are count, DESTRUCTOR as they are used with libraries are not, as far as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destructors are included by the built module.
Is this intentional, so, is a module without a MODULE_UNLOAD property in its build file considered a module that does not support being unloaded? If so, why is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI error code?

For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its CONSTRUCTOR function. When this library is included in a module without a MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, is never called and hence the interface remains in the protocol database, despite it pointing to a memory location that is now free. If it is called, the behavior is obviously undefined.

Did I understand something incorrectly, are these modules not supposed to be unloadable or is this a bug?

Thank you,
Marvin.

Re: Regarding UefiDriverEntryPoint unload handler

[Kinney, Michael D]

Hi Marvin,

Yes.  This is intentional.  If MODULE_UNLOAD is not provided, then the module can never be unloaded.  
The LoadImage() services initializes the Unload field to NULL, and if UnloadImage() is called and
the Unload field is NULL, it returns an EFI_UNSUPPORTED.

I do not think the case you describer is possible.  If ProcessModuleUnloadList() returns an error,
then ProcessLibraryDestructorList()is not called.

Since the module is not unloaded, it is still in allocated memory.  How would the protocol point
to a freed buffer?

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marvin H?user
Sent: Wednesday, June 14, 2017 6:41 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding UefiDriverEntryPoint unload handler

Dear developers,

While performing some research tasks, I noticed that when UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD entries are count, DESTRUCTOR as they are used with libraries are not, as far as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destructors are included by the built module.
Is this intentional, so, is a module without a MODULE_UNLOAD property in its build file considered a module that does not support being unloaded? If so, why is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI error code?

For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its CONSTRUCTOR function. When this library is included in a module without a MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, is never called and hence the interface remains in the protocol database, despite it pointing to a memory location that is now free. If it is called, the behavior is obviously undefined.

Did I understand something incorrectly, are these modules not supposed to be unloadable or is this a bug?

Thank you,
Marvin.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: Regarding UefiDriverEntryPoint unload handler

[Marvin Häuser]

Hey Mike,

"if UnloadImage() is called and the Unload field is NULL, it returns an EFI_UNSUPPORTED."
This is the part I missed, my example is impossible in this case.

Thanks,
Marvin.

-----Ursprüngliche Nachricht-----
Von: Kinney, Michael D [mailto:michael.d.kinney@intel.com] 
Gesendet: Donnerstag, 15. Juni 2017 04:51
An: Marvin H?user <Marvin.Haeuser@outlook.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Betreff: RE: Regarding UefiDriverEntryPoint unload handler

Hi Marvin,

Yes.  This is intentional.  If MODULE_UNLOAD is not provided, then the module can never be unloaded.  
The LoadImage() services initializes the Unload field to NULL, and if UnloadImage() is called and the Unload field is NULL, it returns an EFI_UNSUPPORTED.

I do not think the case you describer is possible.  If ProcessModuleUnloadList() returns an error, then ProcessLibraryDestructorList()is not called.

Since the module is not unloaded, it is still in allocated memory.  How would the protocol point to a freed buffer?

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marvin H?user
Sent: Wednesday, June 14, 2017 6:41 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding UefiDriverEntryPoint unload handler

Dear developers,

While performing some research tasks, I noticed that when UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD entries are count, DESTRUCTOR as they are used with libraries are not, as far as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destructors are included by the built module.
Is this intentional, so, is a module without a MODULE_UNLOAD property in its build file considered a module that does not support being unloaded? If so, why is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI error code?

For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its CONSTRUCTOR function. When this library is included in a module without a MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, is never called and hence the interface remains in the protocol database, despite it pointing to a memory location that is now free. If it is called, the behavior is obviously undefined.

Did I understand something incorrectly, are these modules not supposed to be unloadable or is this a bug?

Thank you,
Marvin.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel