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.web10.5639.1617873991530422347 for ; Thu, 08 Apr 2021 02:26: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 C99F544287; Thu, 8 Apr 2021 09:26:27 +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: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <3bfbdd8d-9417-77f4-6444-5841e685548f@posteo.de> From: "Michael Brown" Message-ID: Date: Thu, 8 Apr 2021 10:26:27 +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: <3bfbdd8d-9417-77f4-6444-5841e685548f@posteo.de> 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 09:53, Marvin H=C3=A4user wrote: > On 07.04.21 23:50, Michael Brown wrote: >> 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=20 >> InstallMultipleProtocolInterfaces() will still work now, with no=20 >> modifications required. >=20 > The same is true for the *2_PROTOCOL instances, I do not see how you=20 > distinct between them. Could you elaborate, please? The distinction is very straightforward. If you plan to *remove*=20 support for the older protocols, then you by definition place a burden=20 on all externally maintained code to support both protocols. If the=20 older protocol will continue to be supported then no such burden is creat= ed. This is why I am asking you if your proposed changes require *breaking*=20 backwards compatibility. You still haven't answered this key question. >> You have to remember that UEFI is not a monolithic codebase with a=20 >> single maintaining organisation.=C2=A0 Implementing a *2_PROTOCOL and=20 >> deprecating the original just causes pain for all the code in the=20 >> world that is maintained outside of the EDK2 repository, since that=20 >> code now has to support *both* the old and new protocols. >=20 > I am aware, but actually it's not far from it nowadays. In contrast to=20 > the days of Aptio IV, I believe all big vendors maintain forks of EDK=20 > II. I know the fork nature taints the issue, but also see last quote=20 > comment. This is empirically not true. Buy a selection of devices in the wild,=20 and you'll find a huge amount of non-EDK2 code on them. I would be extremely happy if every vendor just used the EDK2 code: it=20 would make my life a lot easier. But it's not what happens in the real=20 world. > I see that there is no EFI_USB_IO2_PROTOCOL instance to argue by. Yet=20 > there are EFI_BLOCK_IO2_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL. Former, i= n=20 > my opinion, close in nature to your your example, and latter close to=20 > the nature on what I plan to propose. Sorry, but I do not see how what = I=20 > suggest has not been done multiple times in the past already. >=20 > Please also look at it from an angle of trust. How can I trust the=20 > "secure" advertisements of UEFI / EDK II when the specification=20 > *dictates* the usage of intrinsically insecure APIs? > The consequence for security-critical situations would be to necessaril= y=20 > abandon UEFI and come up with a new design. In who's interest is this? Again, we return to the question that you have not yet answered: do your=20 proposed changes require breaking backwards compatibility? Please do answer this question: if you're *not* proposing to break the=20 platform in a way that would prevent older binaries from working without=20 modification, then we have no disagreement! :) >> Don't get me wrong: I *am* in favour of improving the security of=20 >> EDK2, and a formally verified loader is potentially useful for that.=20 >> But I could only consider it a good idea if it can be done without=20 >> making breaking API changes for which I know I will personally have to= =20 >> maintain workarounds for the next ten years. >=20 > Sorry, but you seem to have missed my points regarding these concerns,=20 > at least you did not address them I believe. I don't know why you need=20 > to (actively) maintain workarounds for APIs external code has no reason= =20 > to use, especially when the legacy implementation would quite literally= =20 > be a wrapper function. Thanks, Michael