Re: [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname

["Yao, Jiewen" <jiewen.yao@intel.com>]

I agree. If creating Boot000@ can hit this ASSERT, this ASSERT must be removed. 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 <star.zeng@intel.com>
Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org; Dong, Eric <eric.dong@intel.com>; leif.lindholm@linaro.org
Subject: Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname

On 4 October 2017 at 00:56, Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>> 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<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel