From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 8DDD821CF58B0 for ; Wed, 4 Oct 2017 06:45:45 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP; 04 Oct 2017 06:49:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,477,1500966000"; d="scan'208,217";a="1226952106" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 04 Oct 2017 06:49:06 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 4 Oct 2017 06:49:06 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 4 Oct 2017 06:49:05 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.175]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.152]) with mapi id 14.03.0319.002; Wed, 4 Oct 2017 21:49:03 +0800 From: "Zeng, Star" To: "Yao, Jiewen" , Ard Biesheuvel CC: "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Dong, Eric" , "leif.lindholm@linaro.org" , "Zeng, Star" Thread-Topic: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname Thread-Index: AQHTPGuLwZCwDLQGMUS+/OYgpm51o6LSy5/w//982YCAAAUPAIABXsYg Date: Wed, 4 Oct 2017 13:49:03 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B97E44C@shsmsx102.ccr.corp.intel.com> References: <20171003171727.5641-1-ard.biesheuvel@linaro.org> <0C09AFA07DD0434D9E2A0C6AEB0483103B97E276@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A9CE19A@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9CE19A@shsmsx102.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname 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: Wed, 04 Oct 2017 13:45:45 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Creating Boot000@ with gEfiGlobalVariableGuid can not succeed as it will be= rejected by MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf that = will check the VariableName against UEFI spec "Table 13. Global Variables" = if the VendorGuid is gEfiGlobalVariableGuid. I would suspect there is a bug at other place if the code ends up calling t= his function(EfiBootManagerIsValidLoadOptionVariableName) on L"BootNext". Ard, Is the fix urgent or not for you? I may want to wait for Ruiyu's back to take some look at the detail of it. At the same time, you may help check the code flow in some detail if you ha= ve free time, I think that will be helpful. :) Thanks, Star From: Yao, Jiewen Sent: Wednesday, October 4, 2017 8:18 AM To: Ard Biesheuvel ; Zeng, Star Cc: Ni, Ruiyu ; edk2-devel@lists.01.org; Dong, Eric ; leif.lindholm@linaro.org Subject: RE: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT o= n 'BootNext' varname I agree. If creating Boot000@ can hit this ASSERT, this ASSERT must be remo= ved. Error handling must be used to handle such case. Thank you Yao Jiewen From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard = Biesheuvel Sent: Wednesday, October 4, 2017 8:00 AM To: Zeng, Star > Cc: Ni, Ruiyu >; edk2-devel@l= ists.01.org; Dong, Eric >; leif.lindholm@linaro.org Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT o= n 'BootNext' varname On 4 October 2017 at 00:56, Zeng, Star > wrote: > Hi Ard, > > To me, the ASSERT there seems on purpose to help catch the misuse of that= interface. > Could you share the case you met the ASSERT? > When using the 'fwupdate' Linux tool to perform capsule updates, BootNext is set to the id of the Boot### variable it creates to run fwupx64.efi, which executes in UEFI context. I haven't looked in great detail how exactly the code ends up calling this function on L"BootNext", but the ASSERT () is wrong, because it is called on variable names that are modifiable externally. For example, if I create a variable Boot000@ from the UEFI Shell, the firmware should not crash. > Given that interface is an open API of UefiBootManagerLib, some comments = for the behavior of ASSERT may can be added to be more clear. > I still think the assert should be removed. > Cc Ruiyu who is the expert of this part code. > Thanks, Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel