From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: jiewen.yao@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by groups.io with SMTP; Tue, 11 Jun 2019 21:48:51 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2019 21:48:50 -0700 X-ExtLoop1: 1 Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga006.jf.intel.com with ESMTP; 11 Jun 2019 21:48:50 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 11 Jun 2019 21:48:50 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 11 Jun 2019 21:48:49 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.33]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.83]) with mapi id 14.03.0439.000; Wed, 12 Jun 2019 12:48:47 +0800 From: "Yao, Jiewen" To: "Wang, Jian J" , "devel@edk2.groups.io" CC: "Zhang, Chao B" , "Hernandez Beltran, Jorge" , "Han, Harry" Subject: Re: [PATCH v2 0/3] Common OBB verification feature Thread-Topic: [PATCH v2 0/3] Common OBB verification feature Thread-Index: AQHVH7tR81t7hfjE/0S8nK22Ll0WYaaXZMmQ Date: Wed, 12 Jun 2019 04:48:46 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F6AB00F@shsmsx102.ccr.corp.intel.com> References: <20190610183536.5628-1-jian.j.wang@intel.com> In-Reply-To: <20190610183536.5628-1-jian.j.wang@intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzAwODMyZDQtZDU0Yy00YzdkLTlkMzUtNzgxZWE4NTAxMmFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTUF1UXNtaG92amdHNVVybFBJQTFiSGJ1V0FMSXNJYjcxRHlQVkRiUlVzNENnOHk5S0NCSmlybzJiaDVGTU41RyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jian. Some comment below: 0) Please add what unit test has been done. 1) Can we use UINT64 for Base and Length? typedef struct _HASHED_FV_INFO { UINT32 Base; UINT32 Length; UINT64 Flag; } HASHED_FV_INFO; 2) Can we remove the hard code HASHED_FV_MAX_NUMBER and use more flexible w= ay? #define HASHED_FV_MAX_NUMBER 10 struct _EDKII_PEI_FIRMWARE_VOLUME_INFO_STORED_HASH_FV_PPI { UINTN FvNumber; HASHED_FV_INFO FvInfo[HASHED_FV_MAX_NUMBER]; UINTN HashNumber; FV_HASH_INFO HashInfo[1]; }; 3) can we use better way to organize the table? It is weird to have so many= zero. Why not just use TPM_ALG_xxx as the first field and search? STATIC CONST HASH_ALG_INFO mHashAlgInfo[] =3D { {0, NULL, NULL, NULL, NULL}, // 0000 TPM_ALG_ERROR {0, NULL, NULL, NULL, NULL}, // 0001 TPM_ALG_FIRST {0, NULL, NULL, NULL, NULL}, // 0002 {0, NULL, NULL, NULL, NULL}, // 0003 {0, NULL, NULL, NULL, NULL}, // 0004 TPM_ALG_SHA1 {0, NULL, NULL, NULL, NULL}, // 0005 {0, NULL, NULL, NULL, NULL}, // 0006 TPM_ALG_AES {0, NULL, NULL, NULL, NULL}, // 0007 {0, NULL, NULL, NULL, NULL}, // 0008 TPM_ALG_KEYEDHASH {0, NULL, NULL, NULL, NULL}, // 0009 {0, NULL, NULL, NULL, NULL}, // 000A {SHA256_DIGEST_SIZE, Sha256Init, Sha256Update, Sha256Final, Sha256HashAll= }, // 000B TPM_ALG_SHA256 {SHA384_DIGEST_SIZE, Sha384Init, Sha384Update, Sha384Final, Sha384HashAll= }, // 000C TPM_ALG_SHA384 {SHA512_DIGEST_SIZE, Sha512Init, Sha512Update, Sha512Final, Sha512HashAll= }, // 000D TPM_ALG_SHA512 {0, NULL, NULL, NULL, NULL}, // 000E {0, NULL, NULL, NULL, NULL}, // 000F {0, NULL, NULL, NULL, NULL}, // 0010 TPM_ALG_NULL //{0, NULL, NULL, NULL, NULL}, // 0011 //{0, NULL, NULL, NULL, NULL}, // 0012 TPM_ALG_SM3_256 }; 4) Why not just add one bit say: skip in S3 ? Why need such complexity? #define HASHED_FV_FLAG_SKIP_BOOT_MODE(Mode) LShiftU64 (0x100, (Mode)) #define FV_HASH_FLAG_BOOT_MODE(Mode) LShiftU64 (1, (Mode)) I am not sure how that works. Is boot mode bit start from BIT0 or BIT8 ? I = am confused. if ((StoredHashFvPpi->HashInfo[HashIndex].HashFlag & FV_HASH_FLAG_BOOT_MODE (BootMode)) !=3D 0) { HashInfo =3D &StoredHashFvPpi->HashInfo[HashIndex]; break; } 5) Why the producer want skip both verified boot and measured boot? Is that= legal or illegal? If it is illegal, I prefer use ASSER() to tell people. if ((FvInfo[FvIndex].Flag & HASHED_FV_FLAG_VERIFIED_BOOT) =3D=3D 0 && (FvInfo[FvIndex].Flag & HASHED_FV_FLAG_MEASURED_BOOT) =3D=3D 0) { continue; } 6) I recommend to add one debug message to tell people this is skipped. // // Skip any FV not meant for current boot mode. // if ((FvInfo[FvIndex].Flag & HASHED_FV_FLAG_SKIP_BOOT_MODE (BootMode)) != =3D 0) { continue; } 7) Would you please clarify why and when a platform need report multiple St= artedHashFv ? do { Status =3D PeiServicesLocatePpi ( &gEdkiiPeiFirmwareVolumeInfoStoredHashFvPpiGuid, Instance, NULL, (VOID**)&StoredHashFvPpi ); if (!EFI_ERROR(Status) && StoredHashFvPpi !=3D NULL && StoredHashFvPpi-= >FvNumber > 0) { It will be better, if you can those description in StoredHashFvPpi.h file 8) Same code above, would you please clarify if it is legal or illegal that= StoredHashFvPpi->FvNumber =3D=3D 0 ? If it is illegal, I prefer use ASSERT() Thank you Yao Jiewen > -----Original Message----- > From: Wang, Jian J > Sent: Tuesday, June 11, 2019 2:36 AM > To: devel@edk2.groups.io > Cc: Zhang, Chao B ; Yao, Jiewen > ; Hernandez Beltran, Jorge > ; Han, Harry > Subject: [PATCH v2 0/3] Common OBB verification feature >=20 > >V2: fix parameter description error found by ECC >=20 > https://bugzilla.tianocore.org/show_bug.cgi?id=3D1617 >=20 > Cc: Chao Zhang > Cc: Jiewen Yao > Cc: "Hernandez Beltran, Jorge" > Cc: Harry Han >=20 > Jian J Wang (3): > SecurityPkg: add definitions for OBB verification > SecurityPkg/FvReportPei: implement a common FV verifier and reporter > SecurityPkg: add FvReportPei.inf in dsc for build validation >=20 > SecurityPkg/FvReportPei/FvReportPei.c | 418 > ++++++++++++++++++ > SecurityPkg/FvReportPei/FvReportPei.h | 121 +++++ > SecurityPkg/FvReportPei/FvReportPei.inf | 57 +++ > SecurityPkg/FvReportPei/FvReportPei.uni | 14 + > .../FvReportPei/FvReportPeiPeiExtra.uni | 12 + > .../Ppi/FirmwareVolumeInfoStoredHashFv.h | 61 +++ > SecurityPkg/SecurityPkg.dec | 9 + > SecurityPkg/SecurityPkg.dsc | 5 + > 8 files changed, 697 insertions(+) > create mode 100644 SecurityPkg/FvReportPei/FvReportPei.c > create mode 100644 SecurityPkg/FvReportPei/FvReportPei.h > create mode 100644 SecurityPkg/FvReportPei/FvReportPei.inf > create mode 100644 SecurityPkg/FvReportPei/FvReportPei.uni > create mode 100644 SecurityPkg/FvReportPei/FvReportPeiPeiExtra.uni > create mode 100644 > SecurityPkg/Include/Ppi/FirmwareVolumeInfoStoredHashFv.h >=20 > -- > 2.17.1.windows.2