From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web11.5855.1617875457270053502 for ; Thu, 08 Apr 2021 02:50:58 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=gsJSduch; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 6D10B240106 for ; Thu, 8 Apr 2021 11:50:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617875455; bh=G2zCF4/mDZder69csicki3Y2YugUqgv+KVsC5G8AaAg=; h=Subject:From:To:Date:From; b=gsJSduchtaWJXuS/xiGqUdCCYTl3rvMD2d/DSANXApXMEjFveVjaVdAGxuZwFtb+/ rwcot8PD+9bISLrLYJvS3sNljlWMOGOZyYxd6wt9epbpuYdpbzoVvIwmO+v50vURa3 1RN1osAZ4hbPRuEyEJnfcL1iiecCl7ljFncp0QFtFmWiXjBdnTXWVEfI1jba0l1620 iMUObQTs2EzdYyvhB9O8R36aNvEnzj4Nd4rwz2CY3chzO33pTB/glsbr5Ti2chCaL8 Neiaf1tmKCyfy8lzRknASK5KpGSzvcE2EW0SaaNYLjfZVFgsq7WcM75w8zs4MQ58Ts dOJgIynXu+3+A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGGjV0jRlz9rxP; Thu, 8 Apr 2021 11:50:53 +0200 (CEST) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= To: Michael Brown , 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> Message-ID: <6222359c-7687-b8e4-d164-1b71a0619f3b@posteo.de> Date: Thu, 8 Apr 2021 11:50:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Sorry, I accidentally removed an inline comment when sending. Best regards, Marvin On 08.04.21 11:41, Marvin H=C3=A4user wrote: > Well, I assume this is a misunderstanding. I understood your usage of=20 > "workaround" to be supporting both *_PROTOCOL and *2_PROTOCOL=20 > instances. Yes, backwards-compatibility will be broken in the sense=20 > that the new interface will not be compatible with the old interface.=20 > No, backwards-compatibility will not be broken in the sense that the=20 > old API is absent or malfunctioning. As I *have* said, I imagine there=20 > to be an option (default true) to expose both variants. With default=20 > settings, I want the loader to be at the very least mostly=20 > plug-'n'-play with existing platform drivers and OS loaders from the=20 > real world. "Mostly" can be clarified further once we have a detailed=20 > plan on the changes (and responses to e.g. malformed binary issues=20 > with iPXE and GNU-EFI). > > Best regards, > Marvin > > On 08.04.21 11:26, Michael Brown wrote: >> 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=20 >>>> any change to the way that InstallProtocolInterface() is=20 >>>> implemented or consumed. >>>> >>>> Code written before the invention of=20 >>>> InstallMultipleProtocolInterfaces() will still work now, with no=20 >>>> modifications required. >>> >>> 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.=C2=A0 If you plan to *remove*= =20 >> support for the older protocols, then you by definition place a=20 >> burden on all externally maintained code to support both protocols.=C2= =A0=20 >> If the older protocol will continue to be supported then no such=20 >> burden is created. >> >> This is why I am asking you if your proposed changes require=20 >> *breaking* backwards compatibility.=C2=A0 You still haven't answered t= his=20 >> key question. >> >>>> 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=20 >>>> world that is maintained outside of the EDK2 repository, since that=20 >>>> code now has to support *both* the old and new protocols. >>> >>> I am aware, but actually it's not far from it nowadays. In contrast=20 >>> to the days of Aptio IV, I believe all big vendors maintain forks of=20 >>> EDK II. I know the fork nature taints the issue, but also see last=20 >>> quote comment. >> >> This is empirically not true.=C2=A0 Buy a selection of devices in the=20 >> wild, and you'll find a huge amount of non-EDK2 code on them. It is not about "how much" is EDK II code, but that it is the core. We=20 are talking about things like the dispatcher, I have not ever seen it=20 modified "lately" (Gigabyte modded AMI CORE_PEI and CORE_DXE with their=20 SIO code in Z77, but you get the idea...). I am very well aware of=20 issues with "user-facing" things such as input. >> >> I would be extremely happy if every vendor just used the EDK2 code:=20 >> it would make my life a lot easier.=C2=A0 But it's not what happens in= the=20 >> real world. >> >>> I see that there is no EFI_USB_IO2_PROTOCOL instance to argue by.=20 >>> Yet there are EFI_BLOCK_IO2_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL.=20 >>> Former, in my opinion, close in nature to your your example, and=20 >>> latter close to the nature on what I plan to propose. Sorry, but I=20 >>> do not see how what I suggest has not been done multiple times in=20 >>> the past already. >>> >>> 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=20 >>> necessarily abandon UEFI and come up with a new design. In who's=20 >>> interest is this? >> >> Again, we return to the question that you have not yet answered: do=20 >> your proposed changes require breaking backwards compatibility? >> >> Please do answer this question: if you're *not* proposing to break=20 >> the platform in a way that would prevent older binaries from working=20 >> without 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=20 >>>> that. But I could only consider it a good idea if it can be done=20 >>>> without making breaking API changes for which I know I will=20 >>>> personally have to maintain workarounds for the next ten years. >>> >>> Sorry, but you seem to have missed my points regarding these=20 >>> concerns, at least you did not address them I believe. I don't know=20 >>> why you need to (actively) maintain workarounds for APIs external=20 >>> code has no reason to use, especially when the legacy implementation=20 >>> would quite literally be a wrapper function. >> >> >> >> Thanks, >> >> Michael >