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.web08.5330.1617871990813808612 for ; Thu, 08 Apr 2021 01:53:11 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=IPMf861d; 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 C6EEF24010A for ; Thu, 8 Apr 2021 10:53:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617871987; bh=IlsC2qdpAZN/d2MKDSDCN08lzDQ934NufHcZxi0vdBI=; h=Subject:To:From:Date:From; b=IPMf861dqcwxZ4o4ZiZd2AIOXsDaGMk7xzKmVQiZMdkiN8dydK3HpGPUyByWfEcTF sTweixOKm/4bUp6rnCkb/LY0zRXMSA42zenvwYFpmgCcXZYAvpDNbnL3Y8fpSGKwqF 9R6NaXYKE0B7bHghzU9O+6ueYT4X9gNRZq4dK0VfbkvmcS3GLUKhr6txU2wHFYIGTP ORz/ba5Lx9WIztdcyNtVR6fA/5tyKo5+EpeqTIp/oGi1dHlrTILG2EMGseMVNtSPTV 9AemAxAXngyRCr23odTsatAiuEo0oz+lKQLkPoEfuNFU3IPpvMKNLAZ6SilEmPVzS0 42AuKW5d07icg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGFQp4cXMz6tmB; Thu, 8 Apr 2021 10:53:06 +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> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: <3bfbdd8d-9417-77f4-6444-5841e685548f@posteo.de> Date: Thu, 8 Apr 2021 10:53:06 +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: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 07.04.21 23:50, Michael Brown wrote: > 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=20 >> solution 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=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 new APIs would be a superset of the old ones, latter can be=20 >> implemented with former, as also previously done (*2_PROTOCOL=20 >> instances and shims in e.g. EdkCompatibilityPkg). In some cases, the=20 >> original protocol interfaces were actually deprecated successfully=20 >> from the EDK II code base. I would probably offer PCDs to disable the=20 >> expose of the old APIs, so platforms with little need for=20 >> backwards-compatibility and more focus on security can tighten the=20 >> constraints as they see fit. Considering the shimmed interfaces for=20 >> the old protocols/PPIs/... can be implemented on top of the new=20 >> public API, and the public API must not change, this code would be=20 >> practically maintenance-free too in my opinion. > > 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. 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. >> 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.=C2=A0 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.=C2=A0 But this won't get fixed, because it can't get=20 > fixed without breaking API compatibility. 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, in=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. 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 necessarily=20 abandon UEFI and come up with a new design. In who's interest is this? > (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=20 > EDK2, and a formally verified loader is potentially useful for that.=C2= =A0=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. 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. This could both be a separate driver (Thunk, as=20 in EdkCompatibilityPkg) or integrated (per PCD). In fact, this does need=20 thorough discussion, but my favourite route would be to actually pull=20 some things from the PI specification and make them EDK II=20 implementation details. Best regards, Marvin > > Thanks, > > Michael