From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: michael.a.rothman@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by groups.io with SMTP; Mon, 30 Sep 2019 13:53:00 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2019 13:52:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,568,1559545200"; d="scan'208,217";a="274785480" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga001.jf.intel.com with ESMTP; 30 Sep 2019 13:52:59 -0700 Received: from orsmsx126.amr.corp.intel.com (10.22.240.126) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 30 Sep 2019 13:52:59 -0700 Received: from orsmsx122.amr.corp.intel.com ([169.254.11.236]) by ORSMSX126.amr.corp.intel.com ([169.254.4.156]) with mapi id 14.03.0439.000; Mon, 30 Sep 2019 13:52:59 -0700 From: "Rothman, Michael A" To: "devel@edk2.groups.io" , "jason.spottswood@hpe.com" Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Topic: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Index: AQHVd9BkSKt+C+k1102oa+6PfWO0/KdEsnN+ Date: Mon, 30 Sep 2019 20:52:58 +0000 Message-ID: <709B20DB-2303-422B-9244-C7F9DD6CF535@intel.com> References: <19681.1569876496768913642@groups.io> In-Reply-To: <19681.1569876496768913642@groups.io> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Return-Path: michael.a.rothman@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_709B20DB2303422B9244C7F9DD6CF535intelcom_" --_000_709B20DB2303422B9244C7F9DD6CF535intelcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, Agreed - though that image you sent was challenging for these old ey= es. Black on dark grey? Ack! Thanks, Michael A. Rothman --------------------------------------------------------------- Let no excuse be a barrier to your success. On Sep 30, 2019, at 1:48 PM, "jason.spottswood@hpe.com" > = wrote: In EsrtFmp.c, function CreateEsrtEntry, line 196, the code asserts if the = FMP image hardware instance matches that of an existing instance. This is = fine if the hardware instance is supported. The field is optional though. = In the UEFI spec, "a zero hardware instance means the FMP provider is not = able to determine a unique hardware instance number or a hardware instance = number is not needed." The code below needs to also check if the hardware = instance is supported (by comparing it to zero) before checking it against = existing entries. // // Check to see of FmpImageInfoBuf GUID/HardwareInstance is unique // for (Index =3D 0; Index < *NumberOfDescriptors; Index++) { if (CompareGuid (&HardwareInstances[Index].ImageTypeGuid, &FmpImageInf= oBuf->ImageTypeId)) { if (HardwareInstances[Index].HardwareInstance =3D=3D FmpHardwareInst= ance) { DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Duplicate firmware image descrip= tor with GUID %g HardwareInstance:0x%x\n", &FmpImageInfoBuf->ImageTypeId, F= mpHardwareInstance)); ASSERT ( !CompareGuid (&HardwareInstances[Index].ImageTypeGuid, &FmpImage= InfoBuf->ImageTypeId) || HardwareInstances[Index].HardwareInstance !=3D FmpHardwareInstan= ce ); return EFI_UNSUPPORTED; } } } --_000_709B20DB2303422B9244C7F9DD6CF535intelcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, Agreed - though that image you sent was challenging for these old e= yes. Black on dark grey? Ack!

Thanks,

= Michael A. Rothman

= ---------------------------------------------------------------

Let no excu= se be a barrier to your success.

On Sep 30, 2019, at 1:48 PM, "jason.spottswood@hpe.com" <jason.spottswood@hpe.com> wrote:

In EsrtFmp.c, function CreateEsrtEntry, line 196, the cod= e asserts if the FMP image hardware instance matches that of an existing in= stance. This is fine if the hardware instance is supported. The= field is optional though. In the UEFI spec, "a zero hardware instance means the FMP provider is not able to dete= rmine a unique hardware instance number or a hardware instance number is no= t needed." The code below needs to also check if the hardware in= stance is supported (by comparing it to zero) before checking it against existing entries.
  //
  // Check to see of FmpImageInfoBuf GUID/HardwareInstance is unique
  //
  for (Index =3D 0; Index < *NumberOfDescriptors; Index++) {
    if (CompareGuid (&Hard=
wareInstances[Index].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId)) =
{
      if (HardwareInstances[Index].HardwareInstance =3D=3D FmpHardwareInst=
ance) {
        DEBUG ((DEBUG_ERROR, &=
quot;EsrtFmpDxe: Duplicate firmware image descriptor with GUID %g HardwareI=
nstance:0x%x\n", &FmpImageInfoBuf->ImageTypeId, FmpHardwareInst=
ance));
        ASSERT (
          !CompareGuid (&H=
ardwareInstances[Index].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId=
) ||
          HardwareInstances[Index].HardwareInstance !=3D FmpHardwareInstan=
ce
          );
        return EFI_UNSUPPORTED;
      }
    }
  }

--_000_709B20DB2303422B9244C7F9DD6CF535intelcom_--