From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8F13C21BB2524 for ; Wed, 14 Jun 2017 19:49:55 -0700 (PDT) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 19:51:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,342,1493708400"; d="scan'208";a="113373975" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga005.jf.intel.com with ESMTP; 14 Jun 2017 19:51:11 -0700 Received: from orsmsx160.amr.corp.intel.com (10.22.226.43) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 14 Jun 2017 19:51:10 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.128]) by ORSMSX160.amr.corp.intel.com ([169.254.13.8]) with mapi id 14.03.0319.002; Wed, 14 Jun 2017 19:51:10 -0700 From: "Kinney, Michael D" To: Marvin H?user , "edk2-devel@lists.01.org" , "Kinney, Michael D" Thread-Topic: Regarding UefiDriverEntryPoint unload handler Thread-Index: AdLldyEIkv4S9+5cSlKrMjp1qtw2IAACTPlA Date: Thu, 15 Jun 2017 02:51:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjFlMzViOGUtY2I3Zi00OWQzLWEyYjgtMGJkZWJiOTdlZTAwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IngxdkZxa1UrXC92amZXdkxGMXNXMDluZ0doNFFcL3JWajVNVnFuMkRQKys5RT0ifQ== dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: Regarding UefiDriverEntryPoint unload handler X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 02:49:55 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marvin, Yes. This is intentional. If MODULE_UNLOAD is not provided, then the modu= le can never be unloaded. =20 The LoadImage() services initializes the Unload field to NULL, and if Unloa= dImage() is called and the Unload field is NULL, it returns an EFI_UNSUPPORTED. I do not think the case you describer is possible. If ProcessModuleUnloadL= ist() returns an error, then ProcessLibraryDestructorList()is not called. Since the module is not unloaded, it is still in allocated memory. How wou= ld the protocol point to a freed buffer? Mike -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marv= in 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 UefiDriverEntryPo= int'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), E= FI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destruct= ors are included by the built module. Is this intentional, so, is a module without a MODULE_UNLOAD property in it= s build file considered a module that does not support being unloaded? If s= o, 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 it= s CONSTRUCTOR function. When this library is included in a module without a= MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintError= LevelLib DESTRUCTOR function, which uninstalls the interface, is never call= ed and hence the interface remains in the protocol database, despite it poi= nting 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 b= e 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