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.20; helo=mga02.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 BD925226516A9 for ; Sun, 8 Apr 2018 02:16:27 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2018 02:16:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,423,1517904000"; d="scan'208";a="189663862" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 08 Apr 2018 02:16:26 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 8 Apr 2018 02:16:26 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 8 Apr 2018 02:16:25 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.184]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.43]) with mapi id 14.03.0319.002; Sun, 8 Apr 2018 17:16:23 +0800 From: "Zeng, Star" To: "Kinney, Michael D" , "Yao, Jiewen" , "edk2-devel@lists.01.org" CC: "Zeng, Star" Thread-Topic: [RFC 0/4] Add FmpDevicePkg Thread-Index: AQHTzGzMhaXkv+n2OU2zkih/ElIBrqPwyxaAgAXP/PA= Date: Sun, 8 Apr 2018 09:16:23 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103BAA2F4F@shsmsx102.ccr.corp.intel.com> References: <20180404212834.8644-1-michael.d.kinney@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503AB37626@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC 0/4] Add FmpDevicePkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 09:16:27 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Curious about which tool to generate the FMP_PAYLOAD_HEADER? BaseTools needs to be updated? Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Kinn= ey, Michael D Sent: Thursday, April 5, 2018 8:29 AM To: Yao, Jiewen ; edk2-devel@lists.01.org Subject: Re: [edk2] [RFC 0/4] Add FmpDevicePkg Hi Jiewen, Responses below. =20 A couple require some comments from Sean or Bret. Mike > -----Original Message----- > From: Yao, Jiewen > Sent: Wednesday, April 4, 2018 4:29 PM > To: Kinney, Michael D ;=20 > edk2-devel@lists.01.org > Cc: Sean Brogan > Subject: RE: [RFC 0/4] Add FmpDevicePkg >=20 > Hi Mike > It is great to see this feature. Thanks for doing this. >=20 > Some thought below: > 1) Do we must add V1 as suffix for the FmpPayloadHeaderLib? > I think we can just use that FmpPayloadHeaderLib. > If we have second version, we can use > FmpPayloadHeaderLibV2. >=20 It is not a must, but since this library class is designed to manage a vers= ioned header structure with extensibility in mind, I do not see anything wr= ong with V1 in the name. In many cases the exiting use of a 2 suffix in the EDK II is because the or= iginal one was not intending multiple versions but an issue was discovered = later that required a new version.=20 > 2) The check in GetFmpPayloadHeaderSize() seems weird. >=20 > if ((UINTN)FmpPayloadHeader + sizeof > (FMP_PAYLOAD_HEADER) < (UINTN)FmpPayloadHeader || >=20 > If we just want to add overflow check, I suggest we use below. > if ((UINTN)FmpPayloadHeader > (MAX_ADDRESS - sizeof > (FMP_PAYLOAD_HEADER)) || >=20 > I think it is more readable. >=20 Maybe we should use SafeIntLib service instead? > 3) For FmpDeviceLib, the interface definition seems not consistent. >=20 > Most of them return EFI_STATUS, such as: > EFI_STATUS > EFIAPI > FmpDeviceGetLowestSupportedVersion ( > OUT UINT32 *LowestSupportedVersion > ) >=20 > But some return data directly, such as: > CHAR16 * > EFIAPI > FmpDeviceGetVersionString ( > VOID > ) >=20 > Can we make them consistent to return EFI_STATUS for all? Such as=20 > EFI_STATUS EFIAPI FmpDeviceGetVersionString ( > OUT CHAR16 **VersionString > ) >=20 I agree they are inconsistent. These APIs are the same as the ones from MS= _UEFI GitHub branch and I did not change the API design. It appears that s= ome of the APIs in the FmpDeviceLib are optimized for how they are used by = the FmpDxe component. > 4) Do we need GetPackageVersion() and > GetPackageVersionName() ? No. >=20 > 5) I found FmpDxe driver returns unsupported for > GetPackageInfo() and SetPackageInfo(). > It means that an implementation cannot use FmpDxe driver as template,=20 > if it wants to support those 2. >=20 > Is there any design limitation ? Yes. This simplified Firmware Management Protocol Implementation does not = support Get/Set PackageInfo(). The UEFI Specification allows these APIs to return EFI_UNSUPPORTED, and for= this firmware update use case they are not required. If a Firmware Manage= ment Protocol implementation requires Get/Set PackageInfo() then FmpDxe sho= uld not be used. >=20 > 6) for variable set, I do not think we need get and compare. > I think variable driver already did that for us. The caller can just=20 > set the variable. >=20 > VOID > SetVersionInVariable ( > UINT32 Version > ) > { > EFI_STATUS Status; > UINT32 Current; >=20 > Status =3D EFI_SUCCESS; >=20 > Current =3D GetVersionFromVariable(); > if (Current !=3D Version) { > Status =3D gRT->SetVariable ( > VARNAME_VERSION, > &gEfiCallerIdGuid, > EFI_VARIABLE_NON_VOLATILE |=20 > EFI_VARIABLE_BOOTSERVICE_ACCESS, > sizeof (Version), > &Version > ); >=20 Does the UEFI Specification require the compare on set? If not, then is there any harm in doing this check?=20 > 7) for LockAllVars(), I found it only happens in non flash_update boot=20 > mode. > I think we should also do in flash_update boot mode, after the capsule=20 > is processed. >=20 > Or there will be a hole, for the non-reset capsule. >=20 > // > // If the boot mode isn't flash update then we must lock all vars. > // If it is flash update leave them unlocked as the system will not > // boot all the way in flash update mode > // > if (BOOT_ON_FLASH_UPDATE !=3D GetBootModeHob ()) { > LockAllVars (); > } >=20 That is a good point. Maybe Sean had another use case in mind? > 8) I am surprised that we support "*" as variable name. > Will it lock all variables with gEfiCallerIdGuid? >=20 > Status =3D Protocol->RequestToLock (Protocol, L"*", &gEfiCallerIdGuid); >=20 I was equally surprised. I thought it may be a special argument to the EDK= II specific lock protocol. Maybe it is a feature that was not included in= the MS_UEFI branch. >=20 > Thank you > Yao Jiewen >=20 >=20 > > -----Original Message----- > > From: Kinney, Michael D > > Sent: Thursday, April 5, 2018 5:29 AM > > To: edk2-devel@lists.01.org > > Cc: Sean Brogan ; Yao, > Jiewen > > > > Subject: [RFC 0/4] Add FmpDevicePkg > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3D922 > > > > Based on content from the following branch: > > > > > https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsu > leSupport/MsCapsu > > leUpdatePkg > > > > Branch for review: > > > > > https://github.com/mdkinney/edk2/tree/Bug_922_FmpDevice > Pkg > > > > This package provides an implementation of a Firmware > Management Protocol > > instance that supports the update of firmware storage > devices using UEFI > > Capsules. The behavior of the Firmware Management > Protocol instance is > > customized using libraries and PCDs. > > > > Cc: Sean Brogan > > Cc: Jiewen Yao > > Contributed-under: TianoCore Contribution Agreement > 1.1 > > Signed-off-by: Michael D Kinney > > > > > Kinney, Michael D (4): > > FmpDevicePkg: Add package, library classes, and > PCDs > > FmpDevicePkg: Add library instances > > FmpDevicePkg: Add FmpDxe module > > FmpDevicePkg: Add DSC file to build all package > components > > > > FmpDevicePkg/FmpDevicePkg.dec | > 126 ++ > > FmpDevicePkg/FmpDevicePkg.dsc | > 119 ++ > > FmpDevicePkg/FmpDevicePkg.uni | > 75 + > > FmpDevicePkg/FmpDevicePkgExtra.uni | > 18 + > > FmpDevicePkg/FmpDxe/FmpDxe.c | > 1533 > > ++++++++++++++++++++ > > FmpDevicePkg/FmpDxe/FmpDxe.inf | > 96 ++ > > FmpDevicePkg/FmpDxe/FmpDxe.uni | > 20 + > > FmpDevicePkg/FmpDxe/FmpDxeExtra.uni | > 18 + > > FmpDevicePkg/FmpDxe/FmpDxeLib.inf | > 93 ++ > > FmpDevicePkg/FmpDxe/VariableSupport.c | > 431 ++++++ > > FmpDevicePkg/FmpDxe/VariableSupport.h | > 180 +++ > > .../Include/Library/CapsuleUpdatePolicyLib.h | > 120 ++ > > FmpDevicePkg/Include/Library/FmpDeviceLib.h | > 385 +++++ > > FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h | > 100 ++ > > .../CapsuleUpdatePolicyLibNull.c | > 136 ++ > > .../CapsuleUpdatePolicyLibNull.inf | > 45 + > > .../CapsuleUpdatePolicyLibNull.uni | > 17 + > > .../Library/FmpDeviceLibNull/FmpDeviceLib.c | > 395 +++++ > > .../Library/FmpDeviceLibNull/FmpDeviceLibNull.inf | > 48 + > > .../Library/FmpDeviceLibNull/FmpDeviceLibNull.uni | > 18 + > > .../FmpPayloadHeaderLibV1/FmpPayloadHeaderLib.c | > 188 +++ > > .../FmpPayloadHeaderLibV1.inf | > 48 + > > .../FmpPayloadHeaderLibV1.uni | > 21 + > > 23 files changed, 4230 insertions(+) create mode 100644=20 > > FmpDevicePkg/FmpDevicePkg.dec create mode 100644=20 > > FmpDevicePkg/FmpDevicePkg.dsc create mode 100644=20 > > FmpDevicePkg/FmpDevicePkg.uni create mode 100644 > FmpDevicePkg/FmpDevicePkgExtra.uni > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.c create mode 100644=20 > > FmpDevicePkg/FmpDxe/FmpDxe.inf create mode 100644=20 > > FmpDevicePkg/FmpDxe/FmpDxe.uni create mode 100644 > FmpDevicePkg/FmpDxe/FmpDxeExtra.uni > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeLib.inf create mode=20 > > 100644 > FmpDevicePkg/FmpDxe/VariableSupport.c > > create mode 100644 > FmpDevicePkg/FmpDxe/VariableSupport.h > > create mode 100644 > FmpDevicePkg/Include/Library/CapsuleUpdatePolicyLib.h > > create mode 100644 > FmpDevicePkg/Include/Library/FmpDeviceLib.h > > create mode 100644 > FmpDevicePkg/Include/Library/FmpPayloadHeaderLib.h > > create mode 100644 > > > FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/Capsule > UpdatePolicyLibNull > > .c > > create mode 100644 > > > FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/Capsule > UpdatePolicyLibNull > > .inf > > create mode 100644 > > > FmpDevicePkg/Library/CapsuleUpdatePolicyLibNull/Capsule > UpdatePolicyLibNull > > .uni > > create mode 100644 > > FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c > > create mode 100644 > > > FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull. > inf > > create mode 100644 > > > FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLibNull. > uni > > create mode 100644 > > > FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHe > aderLib.c > > create mode 100644 > > > FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHe > aderLibV1.inf > > create mode 100644 > > > FmpDevicePkg/Library/FmpPayloadHeaderLibV1/FmpPayloadHe > aderLibV1.uni > > > > -- > > 2.14.2.windows.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel