public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Spottswood, Jason" <jason.spottswood@hpe.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Rothman, Michael A" <michael.a.rothman@intel.com>
Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs
Date: Tue, 1 Oct 2019 21:20:31 +0000	[thread overview]
Message-ID: <CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0@CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B9DCE5A4@ORSMSX113.amr.corp.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 7146 bytes --]

Hey Mike,

Specifically, my team has run into ASSERTs on systems loaded 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 to print the FMP version. (We commented out the ASSERT to gather the log.)

Given the current text in the UEFI spec, I do not believe 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 instance description says this field is optional.
 ///
  /// An optional number to identify the unique hardware instance within the system for
  /// 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 determined.
 /// 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 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 only requirement, not HW instance.

-Jason

From: Kinney, Michael D <michael.d.kinney@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 <michael.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.  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 unique 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 namespace 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 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 characteristic
  /// 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 able 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 structure 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<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto: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<mailto:michael.a.rothman@intel.com>>; devel@edk2.groups.io<mailto: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 = 0; Index < *NumberOfDescriptors; Index++) {
    if (CompareGuid (&HardwareInstances[Index].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId)) {
      if (HardwareInstances[Index].HardwareInstance == FmpHardwareInstance) {
        DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Duplicate firmware image descriptor with GUID %g HardwareInstance:0x%x\n", &FmpImageInfoBuf->ImageTypeId, FmpHardwareInstance));
        ASSERT (
          !CompareGuid (&HardwareInstances[Index].ImageTypeGuid, &FmpImageInfoBuf->ImageTypeId) ||
          HardwareInstances[Index].HardwareInstance != FmpHardwareInstance
          );
        return EFI_UNSUPPORTED;
      }
    }
  }

-Jason

From: Rothman, Michael A <michael.a.rothman@intel.com<mailto:michael.a.rothman@intel.com>>
Sent: Monday, September 30, 2019 3:53 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Spottswood, Jason <jason.spottswood@hpe.com<mailto: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 eyes. 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<mailto:jason.spottswood@hpe.com>" <jason.spottswood@hpe.com<mailto: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 = 0; Index < *NumberOfDescriptors; Index++) {

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

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

        DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Duplicate firmware image descriptor with GUID %g HardwareInstance:0x%x\n", &FmpImageInfoBuf->ImageTypeId, FmpHardwareInstance));

        ASSERT (

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

          HardwareInstances[Index].HardwareInstance != FmpHardwareInstance

          );

        return EFI_UNSUPPORTED;

      }

    }

  }


[-- Attachment #1.2: Type: text/html, Size: 21770 bytes --]

[-- Attachment #2: serial.txt --]
[-- Type: text/plain, Size: 2539 bytes --]

EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Add new image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0
EsrtFmpDxe:  FmpVersion: 0x3,  HardwareInstance:0x0
EsrtFmpDxe: Duplicate firmware image descriptor with GUID 164FFEF2-15D3-4F7C-BAE6-72097DE8AF78 HardwareInstance:0x0

  reply	other threads:[~2019-10-01 21:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 20:48 Recent changes to EsrtFmp causing ASSERTs jason.spottswood
2019-09-30 20:52 ` [edk2-devel] " Rothman, Michael A
2019-09-30 21:23   ` jason.spottswood
2019-10-01 16:49     ` Sean
2019-10-01 17:30     ` Michael D Kinney
2019-10-01 21:20       ` Spottswood, Jason [this message]
2019-10-02 15:12         ` Michael D Kinney
2019-10-18 21:52           ` scott.wiginton
2019-10-19  1:03             ` Michael D Kinney
2019-10-21 13:12               ` scott.wiginton
2019-10-21 16:30                 ` Michael D Kinney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0@CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox