From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::230; helo=mail-it0-x230.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C692F21E781E0 for ; Tue, 3 Oct 2017 16:56:35 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id f79so1928641ita.1 for ; Tue, 03 Oct 2017 16:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PUVN7Sg3AL8SgWBptTMkdsjAR5VwuzPI2oT0GOTCJFY=; b=ZC3Dc3thHa5rfq8PjPpdQrM07UMpgEBQIklBVxjeqBq9GFVcJzw4dThz4gGXwEXhjW pEvIRFsnlDdflQTqgK0gcDdHRG9AqisbOSiRvR/4eZy4Tf0ppEAlz8znbZIkjuyPk4e4 h05X7I7vfTHWYf7dG9nsshBGderu+OiDQiWdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PUVN7Sg3AL8SgWBptTMkdsjAR5VwuzPI2oT0GOTCJFY=; b=BPY8aYZg2Fm+fbn7b5rFOlS/Vs36qStAiILFt0Gq1aiVd6JFgYDyVyi/ru7rti0NA2 4cG0gxtNK+f4PNv0XFLdYzA2Y5+cRgBVEh4b9g4lZGT98OgfBdjG+dpkJbdK+8hRc+iP lyac/lWTG19GqW2MfrLgWB0IZrA2EJoM3QowztTdW8X2+ZWxojgjEURNnzjW/Az4X8Dk gBn+xvlILEAiBDrPtzCFmp4iNdP4BJO3VEsvtTCeIe9yF6IvtUtO5df0aJEI3czBReXD BJ6wvcBmvvbLkJ//trPKeLJpAuKgxj5a/D2xJuszLEGL+EqStVhaHacC8ZAgDX8z9UIz SieQ== X-Gm-Message-State: AMCzsaXTynIDMiyEmwdr2Qla+ovIIowR/o1mMedsg0BWaYiZd5TD6G2C qz1H+bP0iMQzKkzwvAgtmbULawXlO/U5QcExMfKsQg== X-Google-Smtp-Source: AOwi7QCkXCy+/iPE7KHYUI9IFg1SomjketSUgT4WGFIN+ttsj2NY2HNHVUnD+PGZa9e8rttxzVGKKMf+8aC0uEdz28U= X-Received: by 10.36.40.13 with SMTP id h13mr27324777ith.48.1507075195738; Tue, 03 Oct 2017 16:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Tue, 3 Oct 2017 16:59:55 -0700 (PDT) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B97E276@shsmsx102.ccr.corp.intel.com> References: <20171003171727.5641-1-ard.biesheuvel@linaro.org> <0C09AFA07DD0434D9E2A0C6AEB0483103B97E276@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 4 Oct 2017 00:59:55 +0100 Message-ID: To: "Zeng, Star" Cc: "edk2-devel@lists.01.org" , "Dong, Eric" , "leif.lindholm@linaro.org" , "Ni, Ruiyu" 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: Tue, 03 Oct 2017 23:56:36 -0000 Content-Type: text/plain; charset="UTF-8" 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.