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.24, mailfrom: michael.d.kinney@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by groups.io with SMTP; Wed, 02 Oct 2019 08:12:52 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2019 08:12:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,574,1559545200"; d="scan'208,217";a="191823860" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga007.fm.intel.com with ESMTP; 02 Oct 2019 08:12:50 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 2 Oct 2019 08:12:50 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.232]) by ORSMSX152.amr.corp.intel.com ([169.254.8.93]) with mapi id 14.03.0439.000; Wed, 2 Oct 2019 08:12:50 -0700 From: "Michael D Kinney" To: "Spottswood, Jason" , "devel@edk2.groups.io" , "Rothman, Michael A" , "Kinney, Michael D" Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Topic: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Index: AQHVd9BmZ7BYSTaR0kKV5R5yzoXF+qdFJ8wAgAAIjoCAANSNAIAAvOyAgACz9ZA= Date: Wed, 2 Oct 2019 15:12:50 +0000 Message-ID: References: <19681.1569876496768913642@groups.io> <709B20DB-2303-422B-9244-C7F9DD6CF535@intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Return-Path: michael.d.kinney@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E92EE9817A31E24EB0585FDF735412F5B9DCEB71ORSMSX113amrcor_" --_000_E92EE9817A31E24EB0585FDF735412F5B9DCEB71ORSMSX113amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, The only time the HardwareInstance is optional (and set to 0) is if the sy= stem can guarantee that there is at most one instance of the device in the = system. This can only be guaranteed for an integrated device. Any devices= that an end user can add/remove from the system through slots or ports may= potentially have multiple instances and for those FMP use cases the FMP dr= iver must provide a unique HardwareInstance value. You did not quote all the text that applies in point (2) below. You need = the additional sentence in front to know that 0 can only be used if there i= s a guarantee there will never be more than 1 instance. For implementations that will never have more than one instance a zero can be used. A zero means the FMP provider is not able to = determine a unique hardware instance number or a hardware instance number is not neede= d. Only present in version 3 or higher. Mike From: Spottswood, Jason Sent: Tuesday, October 1, 2019 2:21 PM To: Kinney, Michael D ; devel@edk2.groups.io; = Rothman, Michael A Subject: RE: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Hey Mike, Specifically, my team has run into ASSERTs on systems loaded with many ide= ntical model HDDs. Each HDD provides an FMP where the type GUID is identic= al, and the HW instance is not provided (zero). Attached serial log with a= dditional debug output to print the FMP version. (We commented out the ASSE= RT to gather the log.) Given the current text in the UEFI spec, I do not believe the device vendo= r is necessarily at fault here, even if I would like for them to implement = the HW instance. 1. First sentence from the FW image HW instance description says this f= ield is optional. /// /// An optional number to identify the unique hardware instance within t= he system for /// devices that may have multiple instances (Example: a plug in pci net= work card). This 1. Near the end of the FW image HW instance description says that an FM= P can use zero to mean uniqueness cannot be determined. /// instance a zero can be used. A zero means the FMP provider is not abl= e to determine a /// unique hardware instance number or a hardware instance number is not= needed. Only /// present in version 3 or higher. Another point is that the ESRT can only have one entry for each given type= GUID. There is also no HW instance field for entries in the ESRT. As it = relates to building the ESRT, checking for duplicate type GUID/IDs is the o= nly requirement, not HW instance. -Jason From: Kinney, Michael D > Sent: Tuesday, October 1, 2019 12:31 PM To: devel@edk2.groups.io; Spottswood, Jason <= jason.spottswood@hpe.com>; Rothman, Michae= l A >; Kinn= ey, Michael D > Subject: RE: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Hi Jason, I believe the logic to check for uniqueness of FMP Descriptor is correct. The UEFI Spec has 2 structs with HardwareInstance. One is FMP Descriptor = and the other is UEFI Capsule for FMP. The HardwareInstance in FMP must be unique and not 0 unless there is a gua= rantee there is only one instance. /// /// An optional number to identify the unique hardware instance within t= he system for /// devices that may have multiple instances (Example: a plug in pci net= work card). This /// number must be unique within the namespace of the ImageTypeId GUID a= nd /// ImageIndex. For FMP instances that have multiple descriptors for a s= ingle /// hardware instance, all descriptors must have the same HardwareInstan= ce value. /// This number must be consistent between boots and should be based on = some sort of /// hardware identified unique id (serial number, etc) whenever possible= . If a hardware /// based number is not available the FMP provider may use some other ch= aracteristic /// such as device path, bus/dev/function, slot num, etc for generating = the /// HardwareInstance. For implementations that will never have more than= one /// instance a zero can be used. A zero means the FMP provider is not ab= le to determine a /// unique hardware instance number or a hardware instance number is not = needed. Only /// present in version 3 or higher. /// UINT64 HardwareInstance; } EFI_FIRMWARE_IMAGE_DESCRIPTOR; The UEFI Capsule one can be 0 to specify match any. /// /// The HardwareInstance to target with this update. If value is zero it= means match all /// HardwareInstances. This field allows update software to target only = a single device in /// cases where there are more than one device with the same ImageTypeId= GUID. /// This header is outside the signed data of the Authentication Info st= ructure and /// therefore can be modified without changing the Auth data. /// UINT64 UpdateHardwareInstance; } EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER; Best regards, Mike From: devel@edk2.groups.io > On Behalf Of Spottswood, Jason Sent: Monday, September 30, 2019 2:24 PM To: Rothman, Michael A >; devel@edk2.groups.io Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Cut-n-paste problem. My apologies. Copying again in plain text: // // 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; } } } -Jason From: Rothman, Michael A > Sent: Monday, September 30, 2019 3:53 PM To: devel@edk2.groups.io; Spottswood, Jason <= jason.spottswood@hpe.com> Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs 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 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_E92EE9817A31E24EB0585FDF735412F5B9DCEB71ORSMSX113amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

J= ason,

<= o:p> 

T= he only time the HardwareInstance is optional (and set to 0) = is if the system can guarantee that there is at most one instance of the de= vice in the system.  This can only be guaranteed for an integrated device.  Any devices that an end user can add/remove from the system through= slots or ports may potentially have multiple instances and for those FMP u= se cases the FMP driver must provide a unique HardwareInstance value.

<= o:p> 

Y= ou did not quote all the text that applies in point (2) below.  You need the additional sentence in front to know that 0 can only b= e used if there is a guarantee there will never be more than 1 instance.

<= o:p> 

For implementations that= will never have more than one

instance a zero can be u= sed. A zero means the FMP provider is not able to determine a

unique hardware instance= number or a hardware instance number is not needed. Only

present in version 3 or = higher.=

<= o:p> 

M= ike

<= o:p> 

From: Spottswood, Jason <jason.spottswood@hpe.co= m>
Sent: Tuesday, October 1, 2019 2:21 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk= 2.groups.io; Rothman, Michael A <michael.a.rothman@intel.com>
Subject: RE: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs=

 

Hey Mike,

 

Specifically, my team has run into ASSERTs on systems l= oaded with many identical model HDDs.  Each HDD provides an FMP where = the type GUID is identical, and the HW instance is not provided (zero).  Attached serial log with additional debug output t= o print the FMP version. (We commented out the ASSERT to gather the log.)

 

Given the current text in the UEFI spec, I do not belie= ve the device vendor is necessarily at fault here, even if I would like for= them to implement the HW instance.

 

  1. First sentence from the FW image HW inst= ance description says this field is optional.

 ///

  /// An option= al number to identify the unique hardware instance within the system fo= r

  /// devices that= may have multiple instances (Example: a plug in pci network card). This

 

  1. Near the end of the FW image HW instance= description says that an FMP can use zero to mean uniqueness cannot be det= ermined.

 /// instance a ze= ro can be used. A zero means the FMP provider is not able to determine a

  /// unique ha= rdware instance number or a hardware instance number is not needed. Onl= y

  /// present in v= ersion 3 or higher.

 

Another point is that the ESRT can only have one entry = for each given type GUID.  There is also no HW instance field for entr= ies in the ESRT.  As it relates to building the ESRT, checking for duplicate type GUID/IDs is the only requirement, not HW inst= ance.

 

-Jason

 

From: Kinney, = Michael D <michael.d.kinne= y@intel.com>
Sent: Tuesday, October 1, 2019 12:31 PM
To: devel@edk2.groups.io; Spottswood, Jason <jason.= spottswood@hpe.com>; Rothman, Michael A <michael.a.rothman@intel.com>; Kinney, Michael D <micha= el.d.kinney@intel.com>
Subject: RE: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs=

 

Hi Jason,

 

I believe the logic to check for uniqueness of FMP = Descriptor is correct.

 

The UEFI Spec has 2 structs with HardwareInstance.&= nbsp; One is FMP Descriptor and the other is UEFI Capsule for FMP.

 

The HardwareInstance in FMP must be unique and not = 0 unless there is a guarantee there is only one instance.

 

  ///

  /// An optional number to identify the uniqu= e hardware instance within the system for

  /// devices that may have multiple instances= (Example: a plug in pci network card). This

  /// number must be unique within the namespa= ce of the ImageTypeId GUID and

  /// ImageIndex. For FMP instances that have = multiple descriptors for a single

  /// hardware instance, all descriptors must = have the same HardwareInstance value.

  /// This number must be consistent between b= oots and should be based on some sort of

  /// hardware identified unique id (serial nu= mber, etc) whenever possible. If a hardware

  /// based number is not available the FMP pr= ovider may use some other characteristic

  /// such as device path, bus/dev/function, s= lot num, etc for generating the

  /// HardwareInstance. For implementations th= at will never have more than one

  /// instance a zero can be used. A zero mean= s the FMP provider is not able to determine a

 /// unique hardware instance number or a hard= ware instance number is not needed. Only

  /// present in version 3 or higher.

  ///

  UINT64      &n= bsp;            = ;        HardwareInstance;

} EFI_FIRMWARE_IMAGE_DESCRIPTOR;

 

The UEFI Capsule one can be 0 to specify match any.=

 

  ///

  /// The HardwareInstance to target with this= update. If value is zero it means match all

  /// HardwareInstances. This field allows upd= ate software to target only a single device in

  /// cases where there are more than one devi= ce with the same ImageTypeId GUID.

  /// This header is outside the signed data o= f the Authentication Info structure and

  /// therefore can be modified without changi= ng the Auth data.

  ///

  UINT64   UpdateHardwareInstance;

} EFI_FIRMWARE_MANAGEMENT_CAPSULE_IMAGE_HEADER;

 

Best regards,

 

Mike

 

 

From: devel@edk2.groups.io <devel= @edk2.groups.io> On Behalf Of Spottswood, Jason
Sent: Monday, September 30, 2019 2:24 PM
To: Rothman, Michael A <michael.a.rothman@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs=

 

Cut-n-paste problem. My apologies. 

 

Copying again in plain text:

 

  //

  // Check to see of FmpImageInfoBuf GUID/HardwareInsta= nce is unique

  //

  for (Index =3D 0; Index < *NumberOfDescriptors; In= dex++) {

    if (CompareGuid (&HardwareInstances[I= ndex].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId)) {

      if (HardwareInstances[Index].= HardwareInstance =3D=3D FmpHardwareInstance) {

        DEBUG ((DEBUG_ERR= OR, "EsrtFmpDxe: Duplicate firmware image descriptor with GUID %g Hard= wareInstance:0x%x\n", &FmpImageInfoBuf->ImageTypeId, FmpHardwar= eInstance));

        ASSERT (

          !Comp= areGuid (&HardwareInstances[Index].ImageTypeGuid, &FmpImageInfoBuf-= >ImageTypeId) ||

          Hardw= areInstances[Index].HardwareInstance !=3D FmpHardwareInstance

          );

        return EFI_UNSUPP= ORTED;

      }

    }

  }

 

-Jason

 

From: Rothman,= Michael A <michael.a.rot= hman@intel.com>
Sent: Monday, September 30, 2019 3:53 PM
To: devel@edk2.groups.io; Spottswood, Jason <jason.= spottswood@hpe.com>
Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs=

 

Jason, Agreed - thou= gh that image you sent was challenging for these old eyes. Black on dark gr= ey? 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" <jason.spottswood@hpe.com> wrote:

In EsrtFmp.c, functi= on CreateEsrtEntry, line 196, the code asserts if the FMP image hardware in= stance matches that of an existing instance.  This is fine if the hard= ware instance is supported.  The field is optional though.  In the UEFI spec, "a zero hardware instance m= eans the FMP provider is not able to determine a unique hardware instance n= umber or a hardware instance number is not needed."  The code bel= ow needs to also check if the hardware instance is supported (by comparing it to zero) before checking it against existing entries.

  //
  // Ch=
eck to see of FmpImageInfoBuf GUID/HardwareInstance is unique
  //
  for (=
Index =3D 0; Index < *NumberOfDescriptors; Index++) {=

  =
  if (CompareGuid (&HardwareInstances[Index].ImageTypeGuid,=
 &FmpImageInfoBuf->ImageTypeId)) {
  =
    if (HardwareInstances[Index].HardwareInstance =3D=3D Fmp=
HardwareInstance) {
  =
      DEBUG ((DEBUG_ERROR, "EsrtFmpDxe=
: Duplicate firmware image descriptor with GUID %g HardwareInstance:0x%x\n&=
quot;, &FmpImageInfoBuf->ImageTypeId, FmpHardwareInstance));
  =
      ASSERT (
  =
        !CompareGuid (&Hardwa=
reInstances[Index].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId) ||<=
o:p>
  =
        HardwareInstances[Index].Hardwar=
eInstance !=3D FmpHardwareInstance
  =
        );
  =
      return EFI_UNSUPPORTED;

  =
    }


  =
  }


  }

--_000_E92EE9817A31E24EB0585FDF735412F5B9DCEB71ORSMSX113amrcor_--