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.web09.5076.1580118441465459075 for ; Mon, 27 Jan 2020 01:47:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@protonmail.com header.s=default header.b=WuGoECci; spf=pass (domain: protonmail.com, ip: 185.70.40.18, mailfrom: vit9696@protonmail.com) Date: Mon, 27 Jan 2020 09:47:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1580118439; bh=U8UZBDbBb6ZqKbElPV7Hh4b/44dyac1HuYImXUIE22s=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=WuGoECcia+wJmsbu+fxGziC1Z4IMXOYthRu8OgB6N0uoNULMj7ZZ5ag/qzi5FO9vL JqyFr0j76s4ZU9L3SsT5pqND/nJ3anFCMwMzO8u9Swwn3kk2/VwDbfVsV29+IFaH2j 2gZJU9Qk+EMrME+Vus9pTYOoyam/Nhiz2zroytmk= To: "Kinney, Michael D" From: "Vitaly Cheptsov" Cc: "devel@edk2.groups.io" Reply-To: vit9696 Subject: Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions Message-ID: <492A300B-1CED-4FF0-98F8-20D1E116DCC0@protonmail.com> In-Reply-To: References: <20200103171242.63839-1-vit9696@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,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Groupsio-MsgNum: 53485 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------62a3f1dcd4b108728cb0495ed3cf1072"; charset=UTF-8 -----------------------62a3f1dcd4b108728cb0495ed3cf1072 Cc: "devel@edk2.groups.io" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Date: Mon, 27 Jan 2020 12:46:07 +0300 From: vit9696 In-Reply-To: Message-Id: <492A300B-1CED-4FF0-98F8-20D1E116DCC0@protonmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) References: <20200103171242.63839-1-vit9696@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.40.2.2.4) Hi Mike, Any progress with this? We would really benefit from this landing in the n= ext stable release. Best, Vitaly > 8 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3., =D0=B2 19:35, Kinney, Michael D =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 -----------------------62a3f1dcd4b108728cb0495ed3cf1072 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBmBAEBCAAQBQJeLrGeCRBPsoxt7Hy0xQAKCRBPsoxt7Hy0xUUZB/46nyd0 fqmOF81Dx0ijP9ZyCl0k9df9IPGisqPOxoZWy9146iX7LZswJJQoVAxPHLkE YWyHOtBqUgmvCh+oEiH8rDg7fcb7vHQLys0FjLzYLz3yIuWr1PrwWK8Xf7qe bfIuf4SLpN9bM7p2v+xiplzLWqDPKCWpJhzH8LoTLng/MGrN7bwgqCgkJkZj AtuObBDT604yncct5iOzg7Sn1RAOo8QeOVvoz5s82y1c5ohWWyz/gh3ZIxxY 5f1DrlI8yFnkvlGNUrGu5tyIrasBtazcMWE3sPHCNT6fPZkP+w+0K8pucsJM x3r3iXebbM2G7qseclbi67Wzwk4V7DOKr0Mx =pUe6 -----END PGP SIGNATURE----- -----------------------62a3f1dcd4b108728cb0495ed3cf1072--