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.web08.52.1617832236240030424 for ; Wed, 07 Apr 2021 14:50:37 -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 9707D4428B; Wed, 7 Apr 2021 21:50:32 +0000 (UTC) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: =?UTF-8?Q?Marvin_H=c3=a4user?= , devel@edk2.groups.io, Laszlo Ersek , Andrew Fish , Michael Kinney References: From: "Michael Brown" Message-ID: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> Date: Wed, 7 Apr 2021 22:50:32 +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 07/04/2021 22:31, Marvin H=C3=A4user wrote: > Sorry, but I do not see why this would be the case. In fact the solutio= n=20 > is (temporary) co-existence, as already is the case with=20 > InstallProtocolInterface() and InstallMultipleProtocolInterfaces() InstallMultipleProtocolInterfaces() is not a breaking change: the=20 existence of InstallMultipleProtocolInterfaces() does not require any=20 change to the way that InstallProtocolInterface() is implemented or=20 consumed. Code written before the invention of InstallMultipleProtocolInterfaces()=20 will still work now, with no modifications required. > the new APIs would be a superset of the old ones, latter can be=20 > implemented with former, as also previously done (*2_PROTOCOL instances= =20 > and shims in e.g. EdkCompatibilityPkg). In some cases, the original=20 > protocol interfaces were actually deprecated successfully from the EDK=20 > II code base. I would probably offer PCDs to disable the expose of the=20 > old APIs, so platforms with little need for backwards-compatibility and= =20 > more focus on security can tighten the constraints as they see fit.=20 > Considering the shimmed interfaces for the old protocols/PPIs/... can b= e=20 > implemented on top of the new public API, and the public API must not=20 > change, this code would be practically maintenance-free too in my opini= on. You have to remember that UEFI is not a monolithic codebase with a=20 single maintaining organisation. Implementing a *2_PROTOCOL and=20 deprecating the original just causes pain for all the code in the world=20 that is maintained outside of the EDK2 repository, since that code now=20 has to support *both* the old and new protocols. > As for your example, I do not believe what is described is "broken".=20 To avoid distraction from that specific example: have a different=20 example. The EFI_USB_IO_PROTOCOL is fundamentally broken from the=20 perspective of implementing a network device driver, since there is=20 simply no way to enqueue a receive buffer that will wait for the next=20 available packet. But this won't get fixed, because it can't get fixed=20 without breaking API compatibility. (Incidentally, I've observed UEFI software in the wild (from Insyde)=20 that works around these UEFI USB specification flaws by having all of=20 the USB drivers bind to private protocols in addition to=20 EFI_USB_IO_PROTOCOL, resulting in device drivers that point-blank fail=20 to work with a standards-conformant UEFI USB host controller driver.) Don't get me wrong: I *am* in favour of improving the security of EDK2,=20 and a formally verified loader is potentially useful for that. But I=20 could only consider it a good idea if it can be done without making=20 breaking API changes for which I know I will personally have to maintain=20 workarounds for the next ten years. Thanks, Michael