From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 E068B2195407C for ; Mon, 24 Apr 2017 07:21:02 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2017 07:21:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,244,1488873600"; d="scan'208";a="252793771" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 24 Apr 2017 07:21:02 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 24 Apr 2017 07:21:02 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.246]) by FMSMSX151.amr.corp.intel.com ([169.254.7.149]) with mapi id 14.03.0319.002; Mon, 24 Apr 2017 07:21:02 -0700 From: "Carsey, Jaben" To: "Jim.Dailey@dell.com" , "edk2-devel@lists.01.org" CC: "Ni, Ruiyu" Thread-Topic: [edk2] Possible UEFI Shell DrvDiag Command Error Thread-Index: AdK8+L4RxkWlrnwTTPKSLk6x8xvGkAADTlXw Date: Mon, 24 Apr 2017 14:21:01 +0000 Message-ID: References: <2c5b3c022bb94ed9bcdbc7e1f2d9c791@ausx13mps339.AMER.DELL.COM> In-Reply-To: <2c5b3c022bb94ed9bcdbc7e1f2d9c791@ausx13mps339.AMER.DELL.COM> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzMxYzliNDYtNjlkZC00ZDg2LWEzMDUtMDQzZjMzOGYzMzlhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkxpZTNkMGFYWHVyVU4xeGNKY1dmR1BZbFJyVGd4UFFUR1wvdzBJQVcweTlnPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.1.200.107] MIME-Version: 1.0 Subject: Re: Possible UEFI Shell DrvDiag Command Error 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: Mon, 24 Apr 2017 14:21:03 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would say the shell should not free the GUID. > -----Original Message----- > From: Jim.Dailey@dell.com [mailto:Jim.Dailey@dell.com] > Sent: Monday, April 24, 2017 5:46 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Carsey, Jaben > Subject: [edk2] Possible UEFI Shell DrvDiag Command Error > Importance: High >=20 > Although this question is about the shell's drvdiag command, the answer > is related to the interpretation of the UEFI specification with respect > to the diagnostics protocol's RunDiagnostics() function. >=20 > Ultimately, the question is, is the drvdiag command in error in trying > to free the ErrorType pointer, or is a driver vendor in error when they > return an ErrorType parameter that does not point to memory that was > allocated using gBS->AllocatePool? >=20 > The diagnostics protocol's RunDiagnostics() function is partially > described in the UEFI spec like this: >=20 > typedef > EFI_STATUS > (EFIAPI *EFI_DRIVER_DIAGNOSTICS2_RUN_DIAGNOSTICS) ( > IN EFI_DRIVER_DIAGNOSTICS2_PROTOCOL *This, > ... > OUT EFI_GUID **ErrorType, > OUT UINTN *BufferSize, > OUT CHAR16 **Buffer > ); >=20 > ... >=20 > ErrorType A GUID that defines the format of the data returned in > Buffer. > BufferSize The size, in bytes, of the data returned in Buffer. > Buffer A buffer that contains a Null-terminated string plus > some additional data whose format is defined by > ErrorType. Buffer is allocated by this function with > EFI_BOOT_SERVICES.AllocatePool(), and it is the > caller's responsibility to free it with a call to > EFI_BOOT_SERVICES.FreePool(). >=20 > After a call to RunDiagnostics, the drvdiag command attempts to free the > ErrorType pointer if it is non-NULL, yet nothing in the UEFI spec says > that this is proper. >=20 > 1234567890123456789012345678901234567890123456789012345678901234567 > 89012 > The UEFI spec goes to great length to point out that *Buffer* must be > allocated by the callee using gBS->AllocatePool and that the caller must > use gBS->FreePool to release the memory once it is no longer needed. > However, there is no such language with respect to ErrorType. >=20 > So, repeating the question, is the drvdiag command in error in trying > to free the ErrorType pointer, or is a driver vendor in error when they > return an ErrorType parameter that does not point to memory that was > allocated using gBS->AllocatePool? >=20 > Regards, > Jim