From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Zeng, Star" <star.zeng@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Dong, Eric" <eric.dong@intel.com>,
"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
"Ni, Ruiyu" <ruiyu.ni@intel.com>
Subject: Re: [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname
Date: Wed, 4 Oct 2017 00:59:55 +0100 [thread overview]
Message-ID: <CAKv+Gu9-3Tyx4wX49B8E5vtiDy-w8EOgtcmgC+8EX7YD94N1Ow@mail.gmail.com> (raw)
In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B97E276@shsmsx102.ccr.corp.intel.com>
On 4 October 2017 at 00:56, Zeng, Star <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.
next prev parent reply other threads:[~2017-10-03 23:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 17:17 [PATCH] MdeModulePkg/UefiBootManagerLib: don't ASSERT on 'BootNext' varname Ard Biesheuvel
2017-10-03 23:56 ` Zeng, Star
2017-10-03 23:59 ` Ard Biesheuvel [this message]
2017-10-04 0:18 ` Yao, Jiewen
2017-10-04 13:49 ` Zeng, Star
2017-10-04 13:54 ` Ard Biesheuvel
2017-10-04 14:09 ` Zeng, Star
2017-10-04 15:06 ` Laszlo Ersek
2017-10-05 7:31 ` Zeng, Star
2017-10-05 7:59 ` Laszlo Ersek
2017-10-05 9:08 ` Yao, Jiewen
2017-10-10 9:12 ` Ni, Ruiyu
2017-10-04 14:40 ` Laszlo Ersek
2017-10-04 15:01 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKv+Gu9-3Tyx4wX49B8E5vtiDy-w8EOgtcmgC+8EX7YD94N1Ow@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox