From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 2A3112194EB70 for ; Thu, 21 Feb 2019 00:36:41 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B81330013A0; Thu, 21 Feb 2019 08:36:40 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-111.rdu2.redhat.com [10.10.120.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7AF135C206; Thu, 21 Feb 2019 08:36:38 +0000 (UTC) To: "Ni, Ray" , edk2-devel@lists.01.org Cc: Dandan Bi , Hao Wu , Jian J Wang , Sean Brogan , Star Zeng References: <20190220081644.8238-1-lersek@redhat.com> <20190220081644.8238-2-lersek@redhat.com> From: Laszlo Ersek Message-ID: <9e5cad87-5f32-37e4-210a-afb904089aff@redhat.com> Date: Thu, 21 Feb 2019 09:36:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Thu, 21 Feb 2019 08:36:40 +0000 (UTC) Subject: Re: [PATCH v2 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 08:36:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/20/19 14:17, Ni, Ray wrote: > On 2/20/2019 4:16 PM, Laszlo Ersek wrote: >> In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there >> may be >> padding between the DataHeader and ReturnStatus members. The >> REPORT_STATUS_CODE_EX() macro starts populating the structure immediately >> after DataHeader, therefore the source data must provide for the padding. >> >> Extract the BmReportImageFailure() function from EfiBootManagerBoot(), >> prepare a zero padding (if any) in a temporary >> EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the >> REPORT_STATUS_CODE_EX() macro invocation. >> >> Cc: Dandan Bi >> Cc: Hao Wu >> Cc: Jian J Wang >> Cc: Ray Ni >> Cc: Sean Brogan >> Cc: Star Zeng >> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539 >> Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745 >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Laszlo Ersek >> --- >> >> Notes: >>      v2: >>      - new in v2 >> >>   MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 + >>   MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c     | 69 >> +++++++++++++++----- >>   2 files changed, 52 insertions(+), 18 deletions(-) >> >> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h >> b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h >> index 978fbff966f6..0fef63fceedf 100644 >> --- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h >> +++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h >> @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, >> EITHER EXPRESS OR IMPLIED. >>   #include >>   #include >>   #include >> +#include >>   #include >>     #include >> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c >> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c >> index 9be1633b7480..ffb98c6c9b83 100644 >> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c >> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c >> @@ -1667,6 +1667,55 @@ BmIsBootManagerMenuFilePath ( >>     return FALSE; >>   } >>   +/** >> +  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about >> LoadImage() or >> +  StartImage() failure. >> + >> +  @param[in] ErrorCode      An Error Code in the Software Class, DXE >> Boot >> +                            Service Driver Subclass. ErrorCode will >> be used to >> +                            compose the Value parameter for status code >> +                            reporting. Must be one of >> +                            EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and >> +                            EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED. >> + >> +  @param[in] FailureStatus  The failure status returned by the boot >> service >> +                            that should be reported. >> +**/ >> +VOID >> +BmReportImageFailure ( > Laszlo, > Thanks for quick fixing this issue. > To match the status code it reports, how about rename the function as > "BmReportLoadFailure"? Sure, I can do that. > Another minor comments in below. >> +  IN UINT32     ErrorCode, >> +  IN EFI_STATUS FailureStatus >> +  ) >> +{ >> +  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData; >> +  VOID                            *PaddingStart; >> +  UINTN                           PaddingSize; >> + >> +  if (!ReportErrorCodeEnabled ()) { >> +    return; >> +  } >> + >> +  ASSERT ( >> +    (ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) || >> +    (ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED) >> +    ); >> + >> +  PaddingStart = &ExtendedData.DataHeader + 1; >> +  PaddingSize = (UINTN) &ExtendedData.ReturnStatus - (UINTN) >> PaddingStart; >> +  ZeroMem (PaddingStart, PaddingSize); > > I prefer "ZeroMem (&ExtendedData, sizeof (ExtendedData))" instead of > introducing local variables such as PaddingStart/PaddingSize. > This makes code more good-looking:). I agree that that looks more natural. I didn't know how much you'd like me to "optimize" this logic. Because, (1) an optimizing compiler can eliminate PaddingSize from the ZeroMem() call (replacing it with a constant); in other words, the PaddingSize calculation would have no runtime cost, (2) the ZeroMem() call would have to clear fewer bytes. I hesitated between the smallest possible ZeroMem() and the easiest-to-read ZeroMem(). I will rework it in v3. > >> +  ExtendedData.ReturnStatus = FailureStatus; >> + >> +  REPORT_STATUS_CODE_EX ( >> +    (EFI_ERROR_CODE | EFI_ERROR_MINOR), >> +    (EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode), >> +    0, >> +    NULL, >> +    NULL, >> +    PaddingStart, > &ExtendedData.DataHeader + 1 > >> +    PaddingSize + sizeof (ExtendedData.ReturnStatus) > sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader) Yes. Thanks, Laszlo >> +    ); >> +} >> + >>   /** >>     Attempt to boot the EFI boot option. This routine sets >> L"BootCurent" and >>     also signals the EFI ready to boot event. If the device path for >> the option >> @@ -1822,15 +1871,7 @@ EfiBootManagerBoot ( >>         // >>         // Report Status Code with the failure status to indicate that >> the failure to load boot option >>         // >> -      REPORT_STATUS_CODE_EX ( >> -        EFI_ERROR_CODE | EFI_ERROR_MINOR, >> -        (EFI_SOFTWARE_DXE_BS_DRIVER | >> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR), >> -        0, >> -        NULL, >> -        NULL, >> -        &Status, >> -        sizeof (EFI_STATUS) >> -        ); >> +      BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, >> Status); >>         BootOption->Status = Status; >>         // >>         // Destroy the RAM disk >> @@ -1911,15 +1952,7 @@ EfiBootManagerBoot ( >>       // >>       // Report Status Code with the failure status to indicate that >> boot failure >>       // >> -    REPORT_STATUS_CODE_EX ( >> -      EFI_ERROR_CODE | EFI_ERROR_MINOR, >> -      (EFI_SOFTWARE_DXE_BS_DRIVER | >> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED), >> -      0, >> -      NULL, >> -      NULL, >> -      &Status, >> -      sizeof (EFI_STATUS) >> -      ); >> +    BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status); >>     } >>     PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) >> OptionNumber); >>   > >