From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0177747628=jason.spottswood@hpe.com) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by groups.io with SMTP; Tue, 01 Oct 2019 14:20:36 -0700 Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x91LCh8q032454 for ; Tue, 1 Oct 2019 21:20:35 GMT Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 2vc9v0cs01-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 Oct 2019 21:20:35 +0000 Received: from G4W9119.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.210.20.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id 4AF9153 for ; Tue, 1 Oct 2019 21:20:34 +0000 (UTC) Received: from G4W9120.americas.hpqcorp.net (2002:10d2:150f::10d2:150f) by G4W9119.americas.hpqcorp.net (2002:10d2:14d6::10d2:14d6) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 1 Oct 2019 21:20:33 +0000 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (15.241.52.11) by G4W9120.americas.hpqcorp.net (16.210.21.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 1 Oct 2019 21:20:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A9u0F0t5iLlQ0sUVyTGkAvvml7yzMUFA+vxYGgUg8jWirMVbktm8D17WyJ8XwIvhxj2pFSo8k74p4E/43cw+kkKPK9MsClv6LH3Up7SiiZJQUsNfSHIieHYTB/fQ8kma+vW2QzXPk8MSmWgajioZNkpcOH8ldZ0zjYePCB4TVUvcajc4r2NZ9E/fplId23AOg95v8HTx1MI5kKdPDPz3+0tHELfrI0xnx/2yoq/bJvDKc/K/D+p0VxFW7cdFld6Dhzkp215wJnawNShlMeaMlCLa1k71T7Vx+20vKGyW4MX/gtnRY6hhV1w7kYGbipp28wHRJSNzfNd8ceg+JVlILA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OpZHhaXB9WsptMbxac76ZbjsHmq8ZfhAmOH6xMmw+5M=; b=VR3aJ5Qh4wqvxaQgsIZ8jFzJdTRTaHL+HHVXfuVfDd9gmHTT+uF8I95fVkOV9gnIyFhCdKpE5AuWoF0ZYXzooDx+TW3dJa+G0hnftXmkl8tci9X4o7nQQj4+m3dFXTigW7wPJ6khSl2ikcmORbG6FsRjIeoqwzLPtXFCxQEfysojV+JE2dONo8WVISWxA29Ko1q+VmV6qbREzWLKFtZ2h4B3iFie3qS37NnC1YRE24/wnO5RqXLif29F323EM6Cc+0tmdur5WL6WeHzQycchmfmmf0u4a+knH1XHGlFBnUbAf3lhLy74HIoBu+H4VDPzZD7bxvLiGjs5TQ13x56jIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM (10.169.13.138) by CS1PR8401MB1048.NAMPRD84.PROD.OUTLOOK.COM (10.169.15.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Tue, 1 Oct 2019 21:20:31 +0000 Received: from CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM ([fe80::5533:5111:6606:ad27]) by CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM ([fe80::5533:5111:6606:ad27%12]) with mapi id 15.20.2305.022; Tue, 1 Oct 2019 21:20:31 +0000 From: "Spottswood, Jason" To: "Kinney, Michael D" , "devel@edk2.groups.io" , "Rothman, Michael A" Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Topic: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Thread-Index: AQHVd9BvxCzZ8I3Aqk66CRXZJUK8kqdEsnMAgAAIRaCAAVGgAIAACzzw Date: Tue, 1 Oct 2019 21:20:31 +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: yes X-MS-TNEF-Correlator: x-originating-ip: [15.211.195.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a85b9205-b5ec-4dd7-7066-08d746b530de x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: CS1PR8401MB1048: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(396003)(346002)(366004)(39860400002)(136003)(376002)(40224003)(199004)(189003)(2906002)(54896002)(55016002)(9686003)(6306002)(8676002)(25786009)(110136005)(316002)(52536014)(81166006)(81156014)(33656002)(6436002)(790700001)(7736002)(14454004)(229853002)(8936002)(6116002)(3846002)(74316002)(486006)(71200400001)(606006)(86362001)(5660300002)(476003)(7696005)(76236002)(102836004)(478600001)(11346002)(446003)(186003)(26005)(236005)(6246003)(256004)(5024004)(14444005)(76116006)(66946007)(99936001)(66446008)(66476007)(66066001)(53546011)(66616009)(66556008)(64756008)(6506007)(2501003)(76176011)(99286004)(71190400001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR8401MB1048;H:CS1PR8401MB1239.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pUouP/+NnEgmEaVL7kslacjzOJBOb4lORy/1QD9DI4aLv2RUD8oLplf4gX9SvgtogPu+Os60xfukfA9dPwKQZSDGiw51P5TdW8beRtJBMiF5kc8ksiP5B8A2MGFgcis6vp8WqlNOKpnuEbt9h4sFwhezNsZFR1zHXQEYRYem8HrUkvKMnNX9KeQn0szGN+vcd5f/IFMOcovHuhwrBC39Zb8WZZzHKb31CkxaqvaZhfutAi1y4c4HoXPqFcL4EPG4u3gLnJHwrzNu3cQ7oD/MkoVEB830uVP/d1Q1jazCyl4pKl4sA6l4ouGRwMwjr3COKepYMMsgHCXWnrqPpuzbQzFRhvxqWnb7nyXHkVISD8kRNvwMgKgKji/WINAjjsdkWbErBI5NXGdAQxe+DMCI2FL7k474MwRzqL1cMdOwAxfqP8RlzBjrw6vcCfu1WK1cfuIkSX4KvSw3Bz0UPyHGsA== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-Network-Message-Id: a85b9205-b5ec-4dd7-7066-08d746b530de X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 21:20:31.7254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x4NVWkUJHpHK5AY1/hAEoNzMyv9kt5CU5G/3yW0yglpyO6k2N6PmhOLuzum/ADq4odSIuaabwKZPUX+MczxjtFbVObsB7MrD62c0HdOYMGA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB1048 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 10 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-01_09:2019-10-01,2019-10-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 clxscore=1015 impostorscore=0 spamscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910010176 X-Groupsio-MsgNum: 48355 Content-Language: en-US Content-Type: multipart/mixed; boundary="_004_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_" --_004_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_ Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_" --_000_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ; Ro= thman, Michael A ; Kinney, 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_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 fr= om the FW image HW instance 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 t= he FW image HW instance description says that an FMP can use zero to mean u= niqueness cannot be determined.

 /// 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.kinney= @intel.com>
Sent: Tuesday, October 1, 2019 12:31 PM
To: devel@edk2.groups.io; Spottswood, Jason <jason.spottswood@hp= e.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.&= 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 <deve= l@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.rothman@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_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_-- --_004_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_ Content-Type: text/plain; name="serial.txt" Content-Description: serial.txt Content-Disposition: attachment; filename="serial.txt"; size=2539; creation-date="Tue, 01 Oct 2019 21:04:25 GMT"; modification-date="Tue, 01 Oct 2019 21:04:25 GMT" Content-Transfer-Encoding: base64 RXNydEZtcER4ZTogIEZtcFZlcnNpb246IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0 Rm1wRHhlOiBBZGQgbmV3IGltYWdlIGRlc2NyaXB0b3Igd2l0aCBHVUlEIDE2NEZGRUYyLTE1RDMt NEY3Qy1CQUU2LTcyMDk3REU4QUY3OCBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTog IEZtcFZlcnNpb246IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiBEdXBs aWNhdGUgZmlybXdhcmUgaW1hZ2UgZGVzY3JpcHRvciB3aXRoIEdVSUQgMTY0RkZFRjItMTVEMy00 RjdDLUJBRTYtNzIwOTdERThBRjc4IEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiAg Rm1wVmVyc2lvbjogMHgzLCAgSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6IER1cGxp Y2F0ZSBmaXJtd2FyZSBpbWFnZSBkZXNjcmlwdG9yIHdpdGggR1VJRCAxNjRGRkVGMi0xNUQzLTRG N0MtQkFFNi03MjA5N0RFOEFGNzggSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6ICBG bXBWZXJzaW9uOiAweDMsICBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogRHVwbGlj YXRlIGZpcm13YXJlIGltYWdlIGRlc2NyaXB0b3Igd2l0aCBHVUlEIDE2NEZGRUYyLTE1RDMtNEY3 Qy1CQUU2LTcyMDk3REU4QUY3OCBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogIEZt cFZlcnNpb246IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiBEdXBsaWNh dGUgZmlybXdhcmUgaW1hZ2UgZGVzY3JpcHRvciB3aXRoIEdVSUQgMTY0RkZFRjItMTVEMy00RjdD LUJBRTYtNzIwOTdERThBRjc4IEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiAgRm1w VmVyc2lvbjogMHgzLCAgSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6IER1cGxpY2F0 ZSBmaXJtd2FyZSBpbWFnZSBkZXNjcmlwdG9yIHdpdGggR1VJRCAxNjRGRkVGMi0xNUQzLTRGN0Mt QkFFNi03MjA5N0RFOEFGNzggSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6ICBGbXBW ZXJzaW9uOiAweDMsICBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogRHVwbGljYXRl IGZpcm13YXJlIGltYWdlIGRlc2NyaXB0b3Igd2l0aCBHVUlEIDE2NEZGRUYyLTE1RDMtNEY3Qy1C QUU2LTcyMDk3REU4QUY3OCBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogIEZtcFZl cnNpb246IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiBEdXBsaWNhdGUg ZmlybXdhcmUgaW1hZ2UgZGVzY3JpcHRvciB3aXRoIEdVSUQgMTY0RkZFRjItMTVEMy00RjdDLUJB RTYtNzIwOTdERThBRjc4IEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiAgRm1wVmVy c2lvbjogMHgzLCAgSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6IER1cGxpY2F0ZSBm aXJtd2FyZSBpbWFnZSBkZXNjcmlwdG9yIHdpdGggR1VJRCAxNjRGRkVGMi0xNUQzLTRGN0MtQkFF Ni03MjA5N0RFOEFGNzggSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6ICBGbXBWZXJz aW9uOiAweDMsICBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogRHVwbGljYXRlIGZp cm13YXJlIGltYWdlIGRlc2NyaXB0b3Igd2l0aCBHVUlEIDE2NEZGRUYyLTE1RDMtNEY3Qy1CQUU2 LTcyMDk3REU4QUY3OCBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogIEZtcFZlcnNp b246IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiBEdXBsaWNhdGUgZmly bXdhcmUgaW1hZ2UgZGVzY3JpcHRvciB3aXRoIEdVSUQgMTY0RkZFRjItMTVEMy00RjdDLUJBRTYt NzIwOTdERThBRjc4IEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiAgRm1wVmVyc2lv bjogMHgzLCAgSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6IER1cGxpY2F0ZSBmaXJt d2FyZSBpbWFnZSBkZXNjcmlwdG9yIHdpdGggR1VJRCAxNjRGRkVGMi0xNUQzLTRGN0MtQkFFNi03 MjA5N0RFOEFGNzggSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6ICBGbXBWZXJzaW9u OiAweDMsICBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogRHVwbGljYXRlIGZpcm13 YXJlIGltYWdlIGRlc2NyaXB0b3Igd2l0aCBHVUlEIDE2NEZGRUYyLTE1RDMtNEY3Qy1CQUU2LTcy MDk3REU4QUY3OCBIYXJkd2FyZUluc3RhbmNlOjB4MA0KRXNydEZtcER4ZTogIEZtcFZlcnNpb246 IDB4MywgIEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiBEdXBsaWNhdGUgZmlybXdh cmUgaW1hZ2UgZGVzY3JpcHRvciB3aXRoIEdVSUQgMTY0RkZFRjItMTVEMy00RjdDLUJBRTYtNzIw OTdERThBRjc4IEhhcmR3YXJlSW5zdGFuY2U6MHgwDQpFc3J0Rm1wRHhlOiAgRm1wVmVyc2lvbjog MHgzLCAgSGFyZHdhcmVJbnN0YW5jZToweDANCkVzcnRGbXBEeGU6IER1cGxpY2F0ZSBmaXJtd2Fy ZSBpbWFnZSBkZXNjcmlwdG9yIHdpdGggR1VJRCAxNjRGRkVGMi0xNUQzLTRGN0MtQkFFNi03MjA5 N0RFOEFGNzggSGFyZHdhcmVJbnN0YW5jZToweDANCg== --_004_CS1PR8401MB1239EEC82C5CFD3CE7610D1E939D0CS1PR8401MB1239_--