From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (NAM02-SN1-obe.outbound.protection.outlook.com [40.107.77.93]) by mx.groups.io with SMTP id smtpd.web10.379.1602088755973818233 for ; Wed, 07 Oct 2020 09:39:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=T8CLj0y9; spf=pass (domain: microsoft.com, ip: 40.107.77.93, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqdYtc4MMDbqYrRbYJ/rXEpdCy/+iq7fCafcIdsOBjqEidpnHu6J2GIqt7sXtTozHMqtKHMRwXaWrtQ2kd2W/VqUZYiCWXvOXk5SA7ad+Yy8I7jUlDJGwcuq0Uwh4QwwsbfNEgndOS5hUvz/p3tg1E96tB5bI6EbjuM7Ew9m8ynqSQEZnMad3oO+E1VWlR5dBLnqGV+yCGbj12UkL5fCMVnlN57T8jzLkgDue2JyO8PNkcLfPJxPbREi7UhTz1nOhLL8fo2PSAMQKsjTRds+0DADjF2WJaD2xUWh9fsjorlKJ6AnAzvqYhWGpeuyLYBg70CNfKTYLyNM2+CWojQ1lA== 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=YCGYrPpQTSvBvNHy91Ak31zRnEEldGVJJA8Vw2UKs6s=; b=n9qiJJYFj4yM5OyvXZWWb9sQR5x5Jej5XBCW25hJk0ZoiJVguYGC9fQSrqiq/rJ/x99nOTSGQGqc4docXW6H6pQBaV5Y4SSf9QJUwtyB3KuA1i7DGyDcr8OQZCHyN7PvpX6miEKWj/+l5A4nW/655IIpkquooQ36eiOAUPx5p4STDI2Lap5s7szpJjWw8aN/UsRxMmZUCAEzGQgV4+ztFeQ9DQqfK77UlUA4voCk4ozs2QvVd/MiW8/zpy0NXpXdUa1EdJZWTDTMER8nqtbNcEIdX62JklkqvGUsrQRcGZpBpDoL4Da1EHi22mYUh6XGsePIoQmUaB8s44SDbeKNkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YCGYrPpQTSvBvNHy91Ak31zRnEEldGVJJA8Vw2UKs6s=; b=T8CLj0y9/6UghSVz6MqTkImof0M7ADwIPhJRP3CdNpRc7wkcx0xy6MmYrQlvBHpJ9U8+hpcJmfPbOoldlAFGpoE4eAnFLnrXG2clo+CiAp+lDFqOZWqocFZoO71QdRCKBvRYo1xSEHK9mp7CHSUdNFMGp1WBDfv3qodOWiXYPdY= Received: from MW4PR21MB1857.namprd21.prod.outlook.com (2603:10b6:303:74::12) by MWHPR21MB0640.namprd21.prod.outlook.com (2603:10b6:300:127::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Wed, 7 Oct 2020 16:39:08 +0000 Received: from MW4PR21MB1857.namprd21.prod.outlook.com ([fe80::2967:7434:51bb:e234]) by MW4PR21MB1857.namprd21.prod.outlook.com ([fe80::2967:7434:51bb:e234%4]) with mapi id 15.20.3477.011; Wed, 7 Oct 2020 16:39:08 +0000 From: "Bret Barkelew" To: "Kinney, Michael D" , Andrew Fish , edk2-devel-groups-io Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering Thread-Topic: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering Thread-Index: AQHWnMXk1DxrbQsLX0+f/XLnepxYJqmMVlmP Date: Wed, 7 Oct 2020 16:39:07 +0000 Message-ID: References: <38FD7E16-93BD-45D1-985A-702A9776D3D3@apple.com>, In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-07T16:36:03.7772527Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.212.128.184] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 53859584-3f45-4775-a927-08d86adf8307 x-ms-traffictypediagnostic: MWHPR21MB0640: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5jZMdBhQQwLaFrxcDTNBImN4xtXeXo2wWk8lDVC0XWF6LalO4E8ZhVJ0Pu8cblUVSKHkS9eKDAhDIPo5w2CZul7wdCvPNXdsuDwSxUgZC9GsBREf1m4oy54a6J5j7fZ8jSlR5L3N0q2gDw4dbKVVp+R0r9BmuQlBTpEdTzDchaUl5VQ4pi+gUAI/MEInvLzn8EeMLrewyo9Z3YUnyvXVf1XBGbXWbz+n/+GWfJNatIkmQHgNUYCUWUcv2bWXYi50IjKz/6IVMQ1Z8G29cYj5BI8qQR4qVInFvk6z49ave7CO76e1ErAH3ZIM/sEwyvCNodXk2PWbGsjGVimuFCi1WAjgkIWwwQLQpyQ7tuTEGtDiEW9v1FJXWgyqI6V8PDPgmRyTx8q0HwUj0PCIOtFYqg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR21MB1857.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(110136005)(186003)(2906002)(478600001)(5660300002)(7696005)(71200400001)(6506007)(53546011)(33656002)(55016002)(99936003)(82960400001)(82950400001)(52536014)(10290500003)(86362001)(83080400001)(66946007)(316002)(26005)(8936002)(66476007)(66616009)(8676002)(9686003)(166002)(966005)(83380400001)(8990500004)(76116006)(66446008)(64756008)(66556008);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: XCyiAJitAEAVFGlEg2JjGg/1qG6Pf6khGL//oKdM0AhqKlMDUM4HHDZgIafUDiFZZ62otdSC6IVF8ZJGh04AXSyOdAmnxWDDbQoWhKaWAZ6x+KNfp64anPkKJTYTZQ9V83msC81GF8RYI8P/AhUSz47TKF48Hp0e1NF4lPykXsdzfsN+7DTx9anoX2dM6kKhIngykBQlhK2cQMnm84x2m5iZ6tPhKI0HY2qZYwYZrbnAs4jrqQ+MRYJxdfQqra45egnZPKyk1hTKBAJCeIsshG0NMyMYLzw+VRLj2tAvtiOCzyupKelE5Lj1GiPZUvoIojI8JRl+v/ChMsxqJmAfokgdU/OdN7ngi5Q0XooW1T/OWs50KOsR5y6ANk5C7Q+cw3ZYm6wJ9RJWIZ98/DZtHbGkJwjOlXjInDoh/NjBCUr3/gjQRWCrkkC2ibQm8MGkVj1LmQDzgPJu1qzGPIQtXK8HzzqYIfTojbUiutiacZNy1oIfx7j/U3VajCOWx0NabI8woEEDgWzMEyTbx0KLhEVoBZiMHSncL6pHPHIcS24cg0AvaORT9NwmM3GJzo7DGUZFECIps0YLEvKUEK6YazykYNacEvmhJE5LFbIYVCiJ6zp2F45p5AdD+QOeOwwsiXrMg7tnjgWyd+n9/sh8wg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR21MB1857.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53859584-3f45-4775-a927-08d86adf8307 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2020 16:39:07.9741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2X3KF2CBTnE1Ct2RaT2NXfEf+xtUOBOYrE0e/stTHZTzX/VnUUz0G6iRfqO4ofUgjTelTawbtXo2Bf9uEVlZZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0640 X-Groupsio-MsgNum: 65993 Content-Language: en-US Content-Type: multipart/related; boundary="_004_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_"; type="multipart/alternative" --_004_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_ Content-Type: multipart/alternative; boundary="_000_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_" --_000_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed with your concern, Mike. This mechanism (and we can document it as s= uch) should NOT be used to accomplish an explicit ordering (a la the =93apr= iori list=94). It=92s just to provide a little separation for two patterns = that we=92ve seen time and again in our code: data/device manipulators and = data/device protectors. It does not eliminate the necessity for platform cr= eators to understand things like driver ordering if they have one driver th= at requires a protocol be installed or a bus connected. - Bret From: Kinney, Michael D Sent: Wednesday, October 7, 2020 9:21 AM To: Andrew Fish; edk2-devel-groups-io; Kinney, Michael D Cc: Bret Barkelew Subject: [EXTERNAL] RE: [edk2-devel] VariablePolicy: Final Changes Thread = 1 - TPL Ordering Hi Andrew, I agree DXE drivers could use a PCD to make it configurable and prevent co= llisions with UEFI defined TPL levels. Bret=92s suggestion of adding a DXE scoped services to create events using= non-UEFI defined TPL levels could be used with these TPL levels from PCDs.= Would also allow DXE drivers to use TPL levels associated with the firmwa= re interrupts in the range 17..30. Perhaps extensions to the DXE Services = Table? Still does not address my concern that many DXE drivers using these extra = TPL levels may run into race conditions if more than one DXE driver selects= the same TPL level. Platform integrators will need to understand the rela= tive priorities of all DXE drivers that use extra TPL levels so they can as= sign values that both avoid collisions with future UEFI specs and prevent r= ace conditions among DXE drivers. Mike From: Andrew Fish Sent: Tuesday, October 6, 2020 7:18 PM To: edk2-devel-groups-io ; Kinney, Michael D Cc: bret.barkelew@microsoft.com Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ord= ering Mike, When I=92ve done things like this in the past I think of making them confi= gurable like via a PCD. In terms of the #defines I think it makes more sense to just do math on th= e spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I=92ve= got an lldb type formatter for TPL and it prints out [+ ] as I think this is the clearest way to do it. Thanks, Andrew Fish On Oct 6, 2020, at 6:54 PM, Michael D Kinney > wrote: Bret, It is likely best to go with the first approach. The discussion on TPL le= vels can continue and you could adopt it in the future if a general solutio= n is identified. TPL 17..30 are reserved by the UEFI Spec for firmware interrupts. So TPL_= NOTIFY_HIGH as defined would not be allowed. I agree that the use of TPL values other than those defined by the UEFI Sp= ec can potentially be used by DXE. However, that DXE usage must be flexibl= e enough to handle a future extension to the UEFI Spec for new TPL levels w= ithout a collision. Instead of defining specific TPL values, you could add a DXE scoped servic= e to allocate the use of a new TPL level that is not being used by UEFI or = other DXE drivers. I will point out that these approaches (defining new TP= L levels or allocating unused TPL levels) just moves the same problem. You= can solve it for the first driver that needs something special. As soon a= s there is more than one driver that need something special at the same TPL= level, the potential for a race condition for ordering will show up again.= So I do not consider adding TPL levels to be a good general solution to t= his problem. Best regards, Mike From: devel@edk2.groups.io > On Behalf Of Bret Barkelew via groups.io<= https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fgroups.i= o%2F&data=3D02%7C01%7Cbret.barkelew%40microsoft.com%7C648157d1494c415019380= 8d86add058c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637376844812012299= &sdata=3DQPFFE2qiERYshhdMKPeBP8qsaXhTpppj79LPtTOytI4%3D&reserved=3D0> Sent: Tuesday, October 6, 2020 5:24 PM To: devel@edk2.groups.io Subject: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Orderin= g As many will be aware, I=92m in the final stages of having Variable Policy= ready for commit. However, after moving the =93Lock=94 event back to EndOf= Dxe, this exposed a race condition in variable services. A quick synopsis of the problem: * Previously, MorLock abused a privileged position by being tightly co= upled to Variable Services, and its lock callback was called directly so th= at it could be strongly ordered with the internal property lock that disabl= es future RequestToLock calls. * VariablePolicy attempted to decouple this (without realizing it was = a problem) and go through formalized interfaces that could ultimately be br= oken out of Variable Services altogether. * However, doing so triggered the race condition, causing an ASSERT wh= en MorLock attempted to lock its variables. * I current have a reimplementation of the strong ordering workaround = that can be previewed at the link below. I have tested that it works the sa= me as the OLD system. * Take a stab at solving the lock ordering problem =B7 corthon/edk2= @e7d0164 (github.com) However, replacing one bad design with another is not what this community = is about (when we can help it), so we=92d like to take a moment to revisit = a conversation that has come up before: expanding the number of supported T= PL levels. Now, I know that the current TPL levels are defined in the UEFI spec and w= e don=92t want to have to change those, but there=92s no reason that we can= come up with not to add some more granularity in the PI spec, dedicated to= platform and implementation ordering (the UEFI spec events will have to re= main on UEFI spec TPLs). Basically there would be a set of DXE Services tha= t allow WaitForEvent, CheckEvent, Event registration at TPLs other than not= ify/callback. The UEFI system table versions of the functions would still = have this restriction but code built with the platform could use the DXE Se= rvices. Right now, any attempt to use a non-UEFI TPL will ASSERT, so we can= keep that in place on the SystemTable interface, but allow the platform to= go around it with DXE Services. Similar functionality would have to be pro= vided by the Mmst, but that=92s already platform-specific and can probably = allow it in all cases. We=92re suggesting something like the below: // // Task priority level // #define TPL_APPLICATION 4 #define TPL_CALLBACK_LOW 7 #define TPL_CALLBACK 8 #define TPL_CALLBACK_HIGH 9 #define TPL_NOTIFY_LOW 15 #define TPL_NOTIFY 16 #define TPL_NOTIFY_HIGH 17 #define TPL_HIGH_LEVEL 31 There=92s already a long-in-the-tooth bug tracking a similar issue: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1676 This proposal is simpler than what=92s in that bug, and would greatly simp= lify some of our event ordering (and code). Thoughts? If this conversation takes too long, I will publish a set of patches that = just go with the lesser solution posted above, but I=92d much rather work t= he problem this way. - Bret --_000_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Agreed with your concern, Mike. This mechanism (and= we can document it as such) should NOT be used to accomplish an explicit o= rdering (a la the =93apriori list=94). It=92s just to provide a little sepa= ration for two patterns that we=92ve seen time and again in our code: data/device manipulators and data/device protector= s. It does not eliminate the necessity for platform creators to understand = things like driver ordering if they have one driver that requires a protoco= l be installed or a bus connected.

 

- Bret

 

 

Hi Andrew,

 

I agree DXE drivers could use a PCD to make it conf= igurable and prevent collisions with UEFI defined TPL levels.

 

Bret=92s suggestion of adding a DXE scoped services= to create events using non-UEFI defined TPL levels could be used with thes= e TPL levels from PCDs.  Would also allow DXE drivers to use TPL level= s associated with the firmware interrupts in the range 17..30.  Perhaps extensions to the DXE Services Table?<= o:p>

 

Still does not address my concern that many DXE dri= vers using these extra TPL levels may run into race conditions if more than= one DXE driver selects the same TPL level.  Platform integrators will= need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values th= at both avoid collisions with future UEFI specs and prevent race conditions= among DXE drivers.

 

Mike

 

From: Andrew Fish <afish@apple.com> Sent: Tuesday, October 6, 2020 7:18 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Mich= ael D <michael.d.kinney@intel.com>
Cc: bret.barkelew@microsoft.com
Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - = TPL Ordering

 

Mike,

 

When I=92ve done things like this in the past I thi= nk of making them configurable like via a PCD. 

 

In terms of the #defines I think it makes more sens= e to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc.  I=92ve= got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clear= est way to do it. 

 

Thanks,=

 

Andrew Fish



 

Bret,

 

It is likely best to go = with the first approach.  <= /span>The discussion on TPL levels can continue and you could adopt it in t= he future if a general solution is identified.

 

TPL 17..30 are reserved = by the UEFI Spec for firmware interrupts.  So TPL_NOTIFY_HIGH as defined would not be allowed.<= o:p>

 

I agree that the use of = TPL values other than those defined by the UEFI Spec can potentially be use= d by DXE.  However, = that DXE usage must be flexible enough to handle a future extension to the UEFI Spec for new TPL levels without a collisio= n.

 

Instead of defining spec= ific TPL values, you could add a DXE scoped service to allocate the use of = a new TPL level that is not being used by UEFI or other DXE drivers. <= span class=3D"apple-converted-space"> I will point out that these approaches (defining new TPL levels or allocati= ng unused TPL levels) just moves the same problem.  You can solve it for the first driver that = needs something special.  <= /span>As soon as there is more than one driver that need something special at the = same TPL level, the potential for a race condition for ordering will show u= p again.  So I do no= t consider adding TPL levels to be a good general solution to this problem.

 

Best regards,=

 

Mike

 

From: devel@edk2.groups.io <devel@edk2.groups.io&g= t; On Behalf Of Bret Bark= elew via groups.io
Sent: Tuesday, Oc= tober 6, 2020 5:24 PM
To: devel@edk2.groups.= io
Subject: [edk2-de= vel] VariablePolicy: Final Changes Thread 1 - TPL Ordering

 

As many will be aware, I= = =92m in the final stages of having Variable Policy ready for commit. Howev= er, after moving the =93Lock=94 event back to EndOfDxe, this exposed a race= condition in variable services.

 

A quick synopsis of the = problem:

  • Previously, MorLock abused a privileged position by being tightly coupled = to Variable Services, and its lock callback was called directly so that it = could be strongly ordered with the internal property lock that disables fut= ure RequestToLock calls.
  • VariablePolicy attempted to decouple this (without realizing it was a prob= lem) and go through formalized interfaces that could ultimately be broken o= ut of Variable Services altogether.
  • However, doing so triggered the race condition, causing an ASSERT when Mor= Lock attempted to lock its variables.
  • I current have a reimplementation of the strong ordering workaround that c= an be previewed at the link below. I have tested that it works the same as = the OLD system.

 

However, replacing one b= ad design with another is not what this community is about (when we can hel= p it), so we=92d like to take a moment to revisit a conversation that has c= ome up before: expanding the number of supported TPL levels.

 

Now, I know that the cur= rent TPL levels are defined in the UEFI spec and we don=92t want to have to= change those, but there=92s no reason that we can come up with not to add = some more granularity in the PI spec, dedicated to platform and implementation ordering (the UEFI spec events will have t= o remain on UEFI spec TPLs). Basically there would be a set of DXE Services= that allow WaitForEvent, CheckEvent, Event registration at TPLs other than= notify/callback.  The UEFI system table versions of the functions would still have this restriction but cod= e built with the platform could use the DXE Services. Right now, any attemp= t to use a non-UEFI TPL will ASSERT, so we can keep that in place on the Sy= stemTable interface, but allow the platform to go around it with DXE Services. Similar functionality would h= ave to be provided by the Mmst, but that=92s already platform-specific and = can probably allow it in all cases.

 

We=92re suggesting somet= hing like the below:

 

//

// Task priority level

//

#define TPL_APPLICATION       4<= /span>

#define TPL_CALLBACK_LOW      7

#define TPL_CALLBACK       =    8

#define TPL_CALLBACK_HIGH     9

#define TPL_NOTIFY_LOW      &nbs= p; 15

#define TPL_NOTIFY       &n= bsp;    16

#define TPL_NOTIFY_HIGH       17=

#define TPL_HIGH_LEVEL      &nbs= p; 31

 

There=92s already a long= -in-the-tooth bug tracking a similar issue:

 

This proposal is simpler= than what=92s in that bug, and would greatly simplify some of our event or= dering (and code).

 

Thoughts?

 

If this conversation tak= es too long, I will publish a set of patches that just go with the lesser s= olution posted above, but I=92d much rather work the problem this way.=

 

- Bret

 

 

--_000_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_-- --_004_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_ Content-Type: image/png; name="7A42A8CF9BBC4E589B6D9D129C3881BD.png" Content-Description: 7A42A8CF9BBC4E589B6D9D129C3881BD.png Content-Disposition: inline; filename="7A42A8CF9BBC4E589B6D9D129C3881BD.png"; size=151; creation-date="Wed, 07 Oct 2020 16:39:07 GMT"; modification-date="Wed, 07 Oct 2020 16:39:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAhAAAAACCAYAAAAJgeUwAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAsSURBVFhH7dZBDQAwDMSw40+qCIZgYFZpCNq/ I5lDUuc+AICNPxCRJEkalzQ/OgYwyMQmSQAAAABJRU5ErkJggg== --_004_MW4PR21MB1857E9F5A8D161BB9A17350DEF0A0MW4PR21MB1857namp_--