From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web12.5922.1617874831199501811 for ; Thu, 08 Apr 2021 02:40:32 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:72b3:d5ff:feb1:e101]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id D80FF44287; Thu, 8 Apr 2021 09:40:23 +0000 (UTC) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: =?UTF-8?Q?Marvin_H=c3=a4user?= , Andrew Fish , edk2-devel-groups-io Cc: Laszlo Ersek , Mike Kinney References: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <1673B28429E5B4FE.4742@groups.io> <29AA7DA3-6760-4F5B-AD01-0FC334B1C095@apple.com> From: "Michael Brown" Message-ID: <46b3594f-01c0-3afe-efb9-971d79d94002@ipxe.org> Date: Thu, 8 Apr 2021 10:40:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/04/2021 10:04, Marvin H=C3=A4user wrote: > Thank you a lot. One thing I noticed is that part of the quote I did no= t=20 > see on the list before, so I marked it below. >=20 > On 08.04.21 00:10, Andrew Fish wrote: >>> The general UEFI (and UEFI PI) is we mostly add new things, and don=E2= =80=99t=20 >>> depreciated things to maintain compatibility. So for example you can=20 >>> add a new Protocol to a handle so you have V1 and V2 of a protocol on= =20 >>> the same handle. An example of this is SimpleTextIn and=20 >>> SimpleTextInEx. SimpleTextIn was modeled on the LCD of a serial=20 >>> terminal (our server roots) so it did not expose modifier keys, or=20 >>> have an easy way to implement snag keys so that is why SimpleTextInEx= =20 >>> got added for the new functional. >=20 > ^ Here; +1 The addition of EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL was really not a good=20 example of how to handle this issue gracefully. Here is the kind of workaround that external code has to implement: it's=20 a perfect example of how this "add a V2 protocol" approach ends up=20 imposing a permanent maintenance burden on external code: https://github.com/ipxe/ipxe/commit/a08244ecc Note that there was absolutely no reason for the specification to=20 require a V2 protocol in order to support Ctrl-, and the EDK2=20 codebase will indeed do the sensible thing and return the ASCII values=20 for Ctrl- via the original EFI_SIMPLE_TEXT_INPUT_PROTOCOL. It=20 would be amazing if, as you suggested, everyone uses the EDK2 codebase=20 and so all public implementations of EFI_SIMPLE_TEXT_INPUT_PROTOCOL=20 would do this sensible thing. Unfortunately, this is not the case. Very large numbers of vendors use=20 some other non-EDK2 implementation that does not do the sensible thing.=20 I have no idea why. It's also worth noting that the addition of=20 EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL opened up a gaping potential security=20 hole related to pointer lifetimes, as documented in the above-linked=20 commit message. TL;DR: please assume that creating a V2 protocol has a very significant=20 cost, and needs to come with benefits that outweigh that very=20 significant cost. If you can achieve what you need without breaking=20 backwards compatibility, then that represents a massive increase in value= . Thanks, Michael