From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.43; helo=mga05.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 31FA322526495 for ; Wed, 4 Apr 2018 17:28:33 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 17:28:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,409,1517904000"; d="scan'208";a="40788427" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga003.jf.intel.com with ESMTP; 04 Apr 2018 17:28:32 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 4 Apr 2018 17:28:32 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.67]) by ORSMSX114.amr.corp.intel.com ([169.254.8.211]) with mapi id 14.03.0319.002; Wed, 4 Apr 2018 17:28:32 -0700 From: "Kinney, Michael D" To: "Yao, Jiewen" , "edk2-devel@lists.01.org" Thread-Topic: [RFC 0/4] Add FmpDevicePkg Thread-Index: AQHTzGzEnyEZc7HBKUeS7d1wjpNr16PxSJtQ Date: Thu, 5 Apr 2018 00:28:31 +0000 Message-ID: References: <20180404212834.8644-1-michael.d.kinney@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503AB37626@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503AB37626@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.139] 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: Thu, 05 Apr 2018 00:28:34 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ; > 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 versioned header structure with extensibility in mind, I do not see anything wrong with V1 in the name. In many cases the exiting use of a 2 suffix in the EDK II is because the original 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 > 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 some of the APIs in=20 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, 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 Management Protocol implementation requires Get/Set PackageInfo() then FmpDxe should 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 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 | > 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 mode. > I think we should also do in flash_update boot mode, > after the capsule 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 FmpDevicePkg/FmpDevicePkg.dec > > create mode 100644 FmpDevicePkg/FmpDevicePkg.dsc > > create mode 100644 FmpDevicePkg/FmpDevicePkg.uni > > create mode 100644 > FmpDevicePkg/FmpDevicePkgExtra.uni > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.c > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.inf > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxe.uni > > create mode 100644 > FmpDevicePkg/FmpDxe/FmpDxeExtra.uni > > create mode 100644 FmpDevicePkg/FmpDxe/FmpDxeLib.inf > > create mode 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