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.web09.5695.1617874906588363665 for ; Thu, 08 Apr 2021 02:41:47 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=lwRZDfBk; 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 47E8A240102 for ; Thu, 8 Apr 2021 11:41:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617874904; bh=EwrmVCsbnGZJF07pQ8+QSlwp9/AT+rIu7fw3u1cgdjc=; h=Subject:To:From:Date:From; b=lwRZDfBk07JulssLW9bntOBeLR9usdUx1J3hSSOC8/h99I5TWKR20TBGxbBeiu9FB 55Tsz+oOcmoRomaJsFx3IkDyL+ZPDG+C8kDZ2ZUeleJ5h6kn4cksYiCOfVsCZdYHGD TAJY2rMWL8ALUq972B++HDE3h8NUAgZfsbBGT4+FbHjT/AAMCxY048n1qhQ3gCQRfk AtDF4fSHH73JU00kk6C0cGfw7cat65oJ1RAsA3tEQGSap9FVM8cagE7E1xKknGvih7 ettKUCnEQjJ1F3mlKBm/xXN0sCEYjH7MJrbVcLp5EvMdrrdIDUlrRwb8cr/i92WTHZ X+qC79R1cF8KQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGGVs2F0Bz6tm6; Thu, 8 Apr 2021 11:41:41 +0200 (CEST) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader 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> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: Date: Thu, 8 Apr 2021 11:41:40 +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 Well, I assume this is a misunderstanding. I understood your usage of=20 "workaround" to be supporting both *_PROTOCOL and *2_PROTOCOL instances.=20 Yes, backwards-compatibility will be broken in the sense that the new=20 interface will not be compatible with the old interface. No,=20 backwards-compatibility will not be broken in the sense that the old API=20 is absent or malfunctioning. As I *have* said, I imagine there to be an=20 option (default true) to expose both variants. With default settings, I=20 want the loader to be at the very least mostly plug-'n'-play with=20 existing platform drivers and OS loaders from the real world. "Mostly"=20 can be clarified further once we have a detailed plan on the changes=20 (and responses to e.g. malformed binary issues 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 implemented=20 >>> 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 burden=20 > on all externally maintained code to support both protocols.=C2=A0 If t= he=20 > older protocol will continue to be supported then no such burden is=20 > created. > > This is why I am asking you if your proposed changes require=20 > *breaking* backwards compatibility.=C2=A0 You still haven't answered th= is=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 w= ild,=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.=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. Yet=20 >> there are EFI_BLOCK_IO2_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL. Former,=20 >> in my opinion, close in nature to your your example, and latter close=20 >> to the nature on what I plan to propose. Sorry, but I do not see how=20 >> what I suggest has not been done multiple times in 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 the=20 > 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 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=20 >>> 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