From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by mx.groups.io with SMTP id smtpd.web12.9832.1581701890973700872 for ; Fri, 14 Feb 2020 09:38:12 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@protonmail.com header.s=default header.b=L6ckOvNv; spf=pass (domain: protonmail.com, ip: 185.70.40.18, mailfrom: vit9696@protonmail.com) Date: Fri, 14 Feb 2020 17:37:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581701887; bh=8+kITAyD6XOa3dpg/3wZLz7G74ZhXPgMt90ul06AUe4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=L6ckOvNv/a5Nr8bH1lTkySdv3WbfxEOkTHR+8+VPlwVmrSsvWh8WivBCN6ZW8CYDN oIZGqmeO6q+rnB3JGvN53A8OrQpxOnqFY0yE4c10DYo8QHMw3lUp3pRJnhFsD3Hv5k 4vZ43gGysexxBf/PILtUYIVqXQ40Kxg2qouWgkA4= To: "Kinney, Michael D" From: "Vitaly Cheptsov" Cc: "devel@edk2.groups.io" , "Gao, Liming" , "Gao, Zhichao" , =?UTF-8?Q?Marvin_H=C3=A4user?= , Laszlo Ersek Reply-To: vit9696 Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions Message-ID: In-Reply-To: References: <20200103171242.63839-1-vit9696@protonmail.com> <492A300B-1CED-4FF0-98F8-20D1E116DCC0@protonmail.com> Feedback-ID: p9QuX-L1wMgUm6nrSvNrf8juLupNs0VSnzXGVXuYDxlEahFdWtaedWDMB9zpwGDklGt7kzs1-RBc0cqz327Gcg==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-0.7 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Groupsio-MsgNum: 54461 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------3e6b5d39e5c1692c8faf0482253d88d6"; charset=UTF-8 -----------------------3e6b5d39e5c1692c8faf0482253d88d6 Cc: "devel@edk2.groups.io" , "Gao, Liming" , "Gao, Zhichao" , =?utf-8?Q?Marvin_H=C3=A4user?= , Laszlo Ersek Content-Type: multipart/alternative; boundary="Apple-Mail=_2059C7BA-DA21-4CB4-8EC6-4B7AF67E8447" Date: Fri, 14 Feb 2020 20:36:50 +0300 From: vit9696 In-Reply-To: Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) References: <20200103171242.63839-1-vit9696@protonmail.com> <492A300B-1CED-4FF0-98F8-20D1E116DCC0@protonmail.com> <9MoxdJ8nml1WYF1JViU2YrwRwoNEP8Bu7Ax0wps7KatP9SiQyoly1LXHuozlAZdVMTsXi1-rcHMh1E5UZN8VyQ==@protonmail.conversationid> Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions To: "Kinney, Michael D" X-Mailer: Apple Mail (2.3608.60.0.2.5) --Apple-Mail=_2059C7BA-DA21-4CB4-8EC6-4B7AF67E8447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Michael, Generalising the approach makes good sense to me, but we need to make an o= bvious distinguishable difference between: - precondition and invariant assertions (i.e. assertions, where function w= ill NOT work if they are violated) - constraint asserts (i.e. assertions, which allow us to spot unintentiona= l behaviour when parsing untrusted data, but which do not break function be= haviour). As we want to use this outside of SafeString, I suggest the following: - Introduce DEBUG_PROPERTY_ASSERT_CONSTRAINT_ENABLED 0x40 bit for PcdDebug= PropertyMask instead of PcdAssertOnSafeStringConstraints. - Introduce DebugAssertConstraintEnabled DebugLib function to check for DE= BUG_PROPERTY_ASSERT_CONSTRAINT_ENABLED. - Introduce ASSERT_CONSTRAINT macro, that will assert only if DebugConstra= intAssertEnabled returns true. - Change SafeString ASSERTS in SAFE_STRING_CONSTRAINT_CHECK to ASSERT_CONS= TRAINTs. - Use ASSERT_CONSTRAINT in other places where necessary. I believe this way lines best with EDK II design. If there are no objectio= ns, I can submit the patch in the beginning of next week. Best wishes, Vitaly > 14 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 20:00, Kinney, Michael= D =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= = =D0=B0): >=20 > Vitaly, > > I want to make sure a feature PCD can be used to disable ASSERT() behavi= or in more than just safe string functions in BaseLib. > > Can we consider changing the name and description of PcdAssertOnSafeStri= ngConstraints to be more generic, so if we find other lib APIs, the name wi= ll make sense? > > Maybe something like: PcdEnableLibraryAssertChecks? Default is TRUE. C= an set to FALSE in DSC file to disable ASSERT() checks. > > Thanks, > > Mike > > > > From: devel@edk2.groups.io > On Behalf Of Vitaly Cheptsov via Grou= ps.Io > Sent: Friday, February 14, 2020 3:55 AM > To: Kinney, Michael D >; Gao, Liming >; Gao, Zhichao >;= devel@edk2.groups.io > Cc: Marvin H=C3=A4user >; Laszlo Ersek = > > Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string = constraint assertions > > Replying as per Liming's request for this to be merged into edk2-stable2= 02002. > > On Mon, Feb 10, 2020 at 14:12, vit9696 > wrote: > Hello, >=20 > It has been quite some time since we submitted the patch with so far no = negative response. As I mentioned previously, my team will strongly benefit= from its landing in EDK II mainline. Since it does not add any regressions= and can be viewed as a feature implementation for the rest of EDK II users= , I request this to be merged upstream in edk2-stable202002. >=20 > Best wishes, > Vitaly >=20 > > 27 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 12:47, vit9696 > =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0=D0=BB(=D0=B0): > >=20 > >=20 > > Hi Mike, > >=20 > > Any progress with this? We would really benefit from this landing in t= he next stable release. > >=20 > > Best, > > Vitaly > >=20 > >> 8 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 19:35, Kinney, Michael D <= michael.d.kinney@intel.com > =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > >>=20 > >>=20 > >> Hi Vitaly, > >>=20 > >> Thanks for the additional background. I would like > >> a couple extra day to review the PCD name and the places > >> the PCD might potentially be used. > >>=20 > >> If we find other APIs where ASSERT() behavior is only > >> valuable during dev/debug to quickly identify misuse > >> with trusted data and the API provides predicable > >> return behavior when ASSERT() is disabled, then I would > >> like to have a pattern we can potentially apply to all > >> these APIs across all packages. > >>=20 > >> Thanks, > >>=20 > >> Mike > >>=20 > >>> -----Original Message----- > >>> From: devel@edk2.groups.io > On > >>> Behalf Of Vitaly Cheptsov via Groups.Io > >>> Sent: Monday, January 6, 2020 10:44 AM > >>> To: Kinney, Michael D > > >>> Cc: devel@edk2.groups.io > >>> Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to > >>> disable safe string constraint assertions > >>>=20 > >>> Hi Mike, > >>>=20 > >>> Yes, the primary use case is for UEFI Applications. We > >>> do not want to disable ASSERT=E2=80=99s completely, as > >>> assertions that make sense, i.e. the ones signalising > >>> about interface misuse, are helpful for debugging. > >>>=20 > >>> I have already explained in the BZ that basically all > >>> safe string constraint assertions make no sense for > >>> handling untrusted data. We find this use case very > >>> logical, as these functions behave properly with > >>> assertions disabled and cover all these error > >>> conditions by the return statuses. In such situation is > >>> not useful for these functions to assert, as we end up > >>> inefficiently reimplementing the logic. I would have > >>> liked the approach of discussing the interfaces > >>> individually, but I struggle to find any that makes > >>> sense from this point of view. > >>>=20 > >>> AsciiStrToGuid will ASSERT when the length of the > >>> passed string is odd. Functions that cannot, ahem, > >>> parse, for us are pretty much useless. > >>> AsciiStrCatS will ASSERT when the appended string does > >>> not fit the buffer. For us this logic makes this > >>> function pretty much equivalent to deprecated and thus > >>> unavailable AsciiStrCat, except it is also slower. > >>>=20 > >>> My original suggestion was to remove the assertions > >>> entirely, but several people here said that they use > >>> them to verify usage errors when handling trusted data. > >>> This makes good sense to me, so we suggest to support > >>> both cases by introducing a PCD in this patch. > >>>=20 > >>> Best wishes, > >>> Vitaly > >>>=20 > >>>> 6 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 21:28, Kinney, Michael D > >>> > =D0= = =BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > >>>>=20 > >>>>=20 > >>>> Hi Vitaly, > >>>>=20 > >>>> Is the use case for UEFI Applications? > >>>>=20 > >>>> There is a different mechanism to disable all > >>> ASSERT() > >>>> statements within a UEFI Application. > >>>>=20 > >>>> If a component is consuming data from an untrusted > >>> source, > >>>> then that component is required to verify the > >>> untrusted > >>>> data before passing it to a function that clearly > >>> documents > >>>> is input requirements. If this approach is followed, > >>> then > >>>> the BaseLib functions can be used "as is" as long as > >>> the > >>>> ASSERT() conditions are verified before calling. > >>>>=20 > >>>> If there are some APIs that currently document their > >>> ASSERT() > >>>> behavior and we think that ASSERT() behavior is > >>> incorrect and > >>>> should be handled by an existing error return value, > >>> then we > >>>> should discuss each of those APIs individually. > >>>>=20 > >>>> Mike > >>>>=20 > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: devel@edk2.groups.io > On > >>>>> Behalf Of Vitaly Cheptsov via Groups.Io > >>>>> Sent: Friday, January 3, 2020 9:13 AM > >>>>> To: devel@edk2.groups.io > >>>>> Subject: [edk2-devel] [PATCH v3 0/1] Add PCD to > >>> disable > >>>>> safe string constraint assertions > >>>>>=20 > >>>>> REF: > >>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D2054 > >>>>>=20 > >>>>> Requesting for merge in edk2-stable202002. > >>>>>=20 > >>>>> Changes since V1: > >>>>> - Enable assertions by default to preserve the > >>> original > >>>>> behaviour > >>>>> - Fix bugzilla reference link > >>>>> - Update documentation in BaseLib.h > >>>>>=20 > >>>>> Vitaly Cheptsov (1): > >>>>> MdePkg: Add PCD to disable safe string constraint > >>>>> assertions > >>>>>=20 > >>>>> MdePkg/MdePkg.dec | 6 ++ > >>>>> MdePkg/Library/BaseLib/BaseLib.inf | 11 +-- > >>>>> MdePkg/Include/Library/BaseLib.h | 74 > >>>>> +++++++++++++------- > >>>>> MdePkg/Library/BaseLib/SafeString.c | 4 +- > >>>>> MdePkg/MdePkg.uni | 6 ++ > >>>>> 5 files changed, 71 insertions(+), 30 deletions(-) > >>>>>=20 > >>>>> -- > >>>>> 2.21.0 (Apple Git-122.2) > >>>>>=20 > >>>>>=20 > >>>>> -=3D-=3D-=3D-=3D-=3D-=3D > >>>>> Groups.io Links: You receive all messages sent= to > >>> this > >>>>> group. > >>>>>=20 > >>>>> View/Reply Online (#52837): > >>>>> https://edk2.groups.io/g/devel/message/52837 > >>>>> Mute This Topic: > >>> https://groups.io/mt/69401948/1643496 > >>>>> Group Owner: devel+owner@edk2.groups.io > >>>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub > >>>>> [michael.d.kinney@intel.com ] > >>>>> -=3D-=3D-=3D-=3D-=3D-=3D > >>>>=20 > >>>=20 > >>>=20 > >>>=20 > >>=20 > >=20 >=20 > > >=20 --Apple-Mail=_2059C7BA-DA21-4CB4-8EC6-4B7AF67E8447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Michael,
<= br class=3D"">
Generalising the approach makes good se= nse to me, but we need to make an obvious distinguishable difference betwee= n:
- precondition and invariant assertions (i.e. asser= tions, where function will NOT work if they are violated)
- constraint asserts (i.e. assertions, which allow us to spot uninte= ntional behaviour when parsing untrusted data, but which do not break funct= ion behaviour).

<= span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">A= s we want to use this outside of SafeString,  I sug= gest the following:
- Introduce DEBUG_PROPERTY_ASSERT_= CONSTRAINT_ENABLED 0x40 bit for PcdDebugPropertyMask instead of P= cdAssertOnSafeStringConstraints.
- Introduce DebugAsse= rtConstraintEnabled DebugLib function to check for DEBUG_PROP= ERTY_ASSERT_CONSTRAINT_ENABLED.
- Introduce ASS= ERT_CONSTRAINT macro, that will assert only if DebugConstraintAssertEn= abled returns true.
- Change SafeSt= ring ASSERTS in SAFE_STRING_CONSTRAINT_CHECK to=  ASSERT_CONSTRAINTs.
- Use ASSERT_CONSTRAINT in other p= laces where necessary.

I believe this way lines best with EDK II design. If th= ere are no objections, I can submit the patch in the beginning of next week= .

<= span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">B= est wishes,
Vitaly
=

14= =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 20:00, Kinney, Michael D &l= t;michael.d.kinney= @intel.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
Vitaly,=
 
I want to make sure a feature PCD can be used to disable A= SSERT() behavior in more than just safe string functions in BaseLib.
 
Can we consider changing the na= me and description of PcdAssertOnSafeStringConstraints to be more generic, so if we find other = lib APIs, the name will make sense?
&nbs= p;
<= span style=3D"font-size: 12pt; font-family: "Courier New";" class= = =3D"">Maybe something like: PcdEnableLibraryAssertChecks?  Defa= ult is TRUE. &n= bsp;Can set to FALSE in DSC file to disable ASSERT() checks.<= o:p class=3D"">
 
Thanks,<= /span>
 
Mike
 
 
 = ;
F= rom: = ;devel@edk2.groups.io <devel= @edk2.groups.io> <= b class=3D"">On Behalf Of Vitaly Cheptsov via Groups.Io
Sent: Friday, February 14, 2020 3= :55 AM
To: Kinney, Michael D <= michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; devel@edk2.groups.io
Cc: Marvin H=C3=A4user <marvin.haeus= er@outlook.com>; Laszlo Ersek <lersek@r= edhat.com>
Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD t= o disable safe string constraint assertions
 
Replying as per Liming's requ= est for this to be merged into edk2-stable202002.
=
 
On Mon, Feb 10, 2020 at 14:12, vit9696= <vit9696@protonmail.com> wrote:

Hello,
It has been quite some time since we submitted the patch with = so far no negative response. As I mentioned previously, my team will strong= ly benefit from its landing in EDK II mainline. Since it does not add any r= egressions and can be viewed as a feature implementation for the rest of ED= K II users, I request this to be merged upstream in edk2-stable202002.

Best wishes,
Vitaly
> 27 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 12:47, vit969= 6 <vit9696@protonmail.com> =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
> 
> 
> Hi Mike,
> 
> Any progress with this? We would really benefit from this landing in= the next stable release.
> 
> Best,
> Vitaly
> 
>> 8 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 19:35, Kinney, M= ichael D <michael.d.kinney@intel.com<= /a>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
&= gt;> 
&g= t;> 
>= ;> Hi Vitaly,
>> 
>> Thanks for the additional background= . I would like
>> a couple extra day to review the PCD = name and the places
>> the PCD might potentially be use= d.
>> 
>> If we find other APIs where ASSERT() behavior is o= nly
>> valuable during dev/debug to quickly identify mi= suse
>> with trusted data and the API provides predicab= le
>> return behavior when ASSERT() is disabled, then I= would
>> like to have a pattern we can potentially app= ly to all
>> these APIs across all packages.
>> 
>> Thanks,
>> 
>> Mike
>> 
>>>= ; -----Original Message-----
>>> From: devel@edk= 2.groups.io <devel@edk2.groups.io> On
>&= gt;> Behalf Of Vitaly Cheptsov via Groups.Io
>>> = Sent: Monday, January 6, 2020 10:44 AM
>>> To: Kinne= y, Michael D <michael.d.kinney@intel.= com>
>>> Cc: devel@edk2.groups.io
>>> Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to=
>>> disable safe string constraint assertions
>>> >>> Hi Mike,
>>> 
>>> Yes, the pr= imary use case is for UEFI Applications. We
>>> do n= ot want to disable ASSERT=E2=80=99s completely, as
>>&g= t; assertions that make sense, i.e. the ones signalising
>= >> about interface misuse, are helpful for debugging.
&= gt;>> 
>>> I have already explained in the BZ that basically all
>>> safe string constraint assertions make no sense for>>> handling untrusted data. We find this use case ver= y
>>> logical, as these functions behave properly wi= th
>>> assertions disabled and cover all these error=
>>> conditions by the return statuses. In such situ= ation is
>>> not useful for these functions to asser= t, as we end up
>>> inefficiently reimplementing the= logic. I would have
>>> liked the approach of discu= ssing the interfaces
>>> individually, but I struggl= e to find any that makes
>>> sense from this point o= f view.
>>>&nb= sp;
>>> AsciiStrToGuid will ASSERT when the l= ength of the
>>> passed string is odd. Functions tha= t cannot, ahem,
>>> parse, for us are pretty much us= eless.
>>> AsciiStrCatS will ASSERT when the appende= d string does
>>> not fit the buffer. For us this lo= gic makes this
>>> function pretty much equivalent t= o deprecated and thus
>>> unavailable AsciiStrCat, e= xcept it is also slower.
>>> 
>>> My original suggesti= on was to remove the assertions
>>> entirely, but se= veral people here said that they use
>>> them to ver= ify usage errors when handling trusted data.
>>> Thi= s makes good sense to me, so we suggest to support
>>&g= t; both cases by introducing a PCD in this patch.
>>>= ; 
>>= > Best wishes,
>>> Vitaly
>>&= gt; 
>&g= t;>> 6 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 21:28, Kinney, Michae= l D
>>> <micha= el.d.kinney@intel.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0):
>>>> 
>>>> 
>>>> Hi Vitaly,
>>>> <= br class=3D"">>>>> Is the use case for UEFI Applications?
>>>> 
>>>> There is a different mechanism to disable = all
>>> ASSERT()
>>>> stat= ements within a UEFI Application.
>>>> 
>>>> If= a component is consuming data from an untrusted
>>>= source,
>>>> then that component is required to = verify the
>>> untrusted
>>>&= gt; data before passing it to a function that clearly
>>= ;> documents
>>>> is input requirements. If th= is approach is followed,
>>> then
>= >>> the BaseLib functions can be used "as is" as long as
>>> the
>>>> ASSERT() conditions = are verified before calling.
>>>> 
>>>> If there= are some APIs that currently document their
>>> ASS= ERT()
>>>> behavior and we think that ASSERT() be= havior is
>>> incorrect and
>>&g= t;> should be handled by an existing error return value,
&= gt;>> then we
>>>> should discuss each of t= hose APIs individually.
>>>> 
>>>> Mike
>>>> <= br class=3D"">>>>> <= /span>
>>>>> -----Original Message-----
>>>>> From:&nb= sp;devel@edk2.groups.io <d= evel@edk2.groups.io> On
>>>>> Behalf Of= Vitaly Cheptsov via Groups.Io
>>>>> Sent: Fri= day, January 3, 2020 9:13 AM
>>>>> To: dev= el@edk2.groups.io
>>>>> Subject: [edk2-dev= el] [PATCH v3 0/1] Add PCD to
>>> disable
>>>>> safe string constraint assertions
>>>>> >>>>> REF:
>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id= =3D2054
>>>>> 
>>>>> Requesting for m= erge in edk2-stable202002.
>>>>> 
>>>>> Ch= anges since V1:
>>>>> - Enable assertions by d= efault to preserve the
>>> original
&g= t;>>>> behaviour
>>>>> - Fix bugzi= lla reference link
>>>>> - Update documentatio= n in BaseLib.h
>>>>> 
>>>>> Vitaly Cheptso= v (1):
>>>>> MdePkg: Add PCD to disable safe s= tring constraint
>>>>> assertions
>>>>> >>>>> MdePkg/MdePkg.dec | 6 ++
&g= t;>>>> MdePkg/Library/BaseLib/BaseLib.inf | 11 +--
>>>>> MdePkg/Include/Library/BaseLib.h | 74
= >>>>> +++++++++++++-------
>>>>>= ; MdePkg/Library/BaseLib/SafeString.c | 4 +-
>>>>= > MdePkg/MdePkg.uni | 6 ++
>>>>> 5 files ch= anged, 71 insertions(+), 30 deletions(-)
>>>>>=  
>>&= gt;>> --
>>>>> 2.21.0 (Apple Git-122.2)<= br class=3D"">>>>>>&nb= sp;
>>>>> 
>>>>> -=3D-=3D-=3D-=3D-= =3D-=3D
>>>>> Groups.io Links: You receive all messages sent to
>>> this
>>>>> group.
>>>>> 
>>>>> View/Reply Online (#52837):
>>>>> https://edk2.groups.io/g/d= evel/message/52837
>>>>> Mute This Topic:<= br class=3D"">>>> https://groups.io/mt/69401948/1643= 496
>>>>> Group Owner: devel+own= er@edk2.groups.io
>>>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>>= >> [michael.d.kinney@intel.com= ]
>>>>> -=3D-=3D-=3D-=3D-=3D-=3D
>>>> 
>>> 
>>> <= br class=3D"">>>> 
>> 
> 

 
 
=

--Apple-Mail=_2059C7BA-DA21-4CB4-8EC6-4B7AF67E8447-- -----------------------3e6b5d39e5c1692c8faf0482253d88d6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBmBAEBCAAQBQJeRtrwCRBPsoxt7Hy0xQAKCRBPsoxt7Hy0xXgxB/96s8YU gqjAb8vfov0ocdlhcS1noAZhMILlHTx1Uppqm2xsAfgKrMjBSLv+NXISfx/N T+TTfX+e+3KFDBRFZ6aP3y4db/j10zmpfdBwGTkQqhpNDAdYARTbd+tJTCYh oQcTtxAnPka/Zlgao66tZsYedxKE1+KXKGsuZSAvXY3vX3EmIKwgf105Y7AV JF5eI1QXvSkwsjUYj6LQSiu1UKuZsbyonIxNfXneJnNienitpDFonhhpb0rH NVTpxMkZCKavpEUtGiQe9GZ+xji0O81mjm/ELwObfZhAXE8UJGkQyL1olIVD kNkzjdqRJ8w6A+s79A6RCAu5uH9jYIaig2I4 =Rp/j -----END PGP SIGNATURE----- -----------------------3e6b5d39e5c1692c8faf0482253d88d6--