From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.apple.com [17.179.253.48]) by mx.groups.io with SMTP id smtpd.web09.329.1617833445666843740 for ; Wed, 07 Apr 2021 15:10:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=kjKtrcT5; spf=pass (domain: apple.com, ip: 17.179.253.48, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 137M2WST026513; Wed, 7 Apr 2021 15:10:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=EOUTYn6i4nafJ0MA5gTNYEJ/ZoVp/mMvjFrS9WI0ivQ=; b=kjKtrcT5hcicdDeNIFECr+KiGBMzUBEEIqi5N1PJjZDiPZ93415D8/LrryfIVoWepfJv o1gD+xMDVYQ71GES0nOznP3phQq2kjd9/9wpuz40TLst16PvhZIZHwzA7cesYiFvn8Ru khLBr+HqtYax3VZa0qIfApOIAPkZGRsAXLxCspxBLUlMf7hnm+d1DkK9pVUVIMEBmJfN heH8pvuz8iVuk7DGc7Fh64QsS7JS6bVbQAIoNlfRhAjUa8LIQyyKwMDLljYljIl4BjA2 oYAwDQeaTQVmrLUFA8GdJI2D0avGSF12B20GpoRs5QPWGQyKozmujFGtDv27W654m6zE +A== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 37rvckrcru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Apr 2021 15:10:45 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QR700U8RS9XNY20@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 07 Apr 2021 15:10:45 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QR700F00S74FB00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Apr 2021 15:10:45 -0700 (PDT) X-Va-A: X-Va-T-CD: f900b3001c7ef03eb53e4f1f41858654 X-Va-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-Va-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-Va-CD: 0 X-Va-ID: f7a960ac-bcc5-4480-81d3-22c66ae35227 X-V-A: X-V-T-CD: f900b3001c7ef03eb53e4f1f41858654 X-V-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-V-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-V-CD: 0 X-V-ID: 4a75f6ba-237d-43f3-a282-0649add4919e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-07_11:2021-04-07,2021-04-07 signatures=0 Received: from [17.235.44.237] (unknown [17.235.44.237]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QR7003A6S9RQB00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Apr 2021 15:10:40 -0700 (PDT) From: "Andrew Fish" Message-id: <29AA7DA3-6760-4F5B-AD01-0FC334B1C095@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader Date: Wed, 07 Apr 2021 15:10:39 -0700 In-reply-to: <1673B28429E5B4FE.4742@groups.io> Cc: Michael Brown , =?utf-8?Q?Marvin_H=C3=A4user?= , Laszlo Ersek , Mike Kinney To: edk2-devel-groups-io , Andrew Fish References: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <1673B28429E5B4FE.4742@groups.io> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-07_10:2021-04-07,2021-04-07 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_762765B2-798C-4F1E-8D08-2DBD8624DF1F" --Apple-Mail=_762765B2-798C-4F1E-8D08-2DBD8624DF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Some of use also sit on the UEFI standards committees so getting changes in= to the specification is possible with in constraints of what the spec commi= ttees find acceptable.=20 Thanks, Andrew Fish > On Apr 7, 2021, at 3:02 PM, Andrew Fish via groups.io wrote: >=20 >=20 >=20 >> On Apr 7, 2021, at 2:50 PM, Michael Brown wrote: >>=20 >> 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 soluti= on is (temporary) co-existence, as already is the case with InstallProtocol= Interface() and InstallMultipleProtocolInterfaces() >>=20 >> InstallMultipleProtocolInterfaces() is not a breaking change: the exist= ence of InstallMultipleProtocolInterfaces() does not require any change to = the way that InstallProtocolInterface() is implemented or consumed. >>=20 >> Code written before the invention of InstallMultipleProtocolInterfaces(= ) will still work now, with no modifications required. >>=20 >>> the new APIs would be a superset of the old ones, latter can be implem= ented with former, as also previously done (*2_PROTOCOL instances and shims= in e.g. EdkCompatibilityPkg). In some cases, the original protocol interfa= ces were actually deprecated successfully from the EDK II code base. I woul= d probably offer PCDs to disable the expose of the old APIs, so platforms w= ith little need for backwards-compatibility and more focus on security can = tighten the constraints as they see fit. Considering the shimmed interfaces= for the old protocols/PPIs/... can be implemented on top of the new public= API, and the public API must not change, this code would be practically ma= intenance-free too in my opinion. >>=20 >> You have to remember that UEFI is not a monolithic codebase with a sing= le maintaining organisation. Implementing a *2_PROTOCOL and deprecating th= e original just causes pain for all the code in the world that is maintaine= d outside of the EDK2 repository, since that code now has to support *both*= the old and new protocols. >>=20 >>> As for your example, I do not believe what is described is "broken".= =20 >>=20 >> To avoid distraction from that specific example: have a different examp= le. The EFI_USB_IO_PROTOCOL is fundamentally broken from the perspective o= f implementing a network device driver, since there is simply no way to enq= ueue a receive buffer that will wait for the next available packet. But th= is won't get fixed, because it can't get fixed without breaking API compati= bility. >>=20 >> (Incidentally, I've observed UEFI software in the wild (from Insyde) th= at works around these UEFI USB specification flaws by having all of the USB= drivers bind to private protocols in addition to EFI_USB_IO_PROTOCOL, resu= lting in device drivers that point-blank fail to work with a standards-conf= ormant UEFI USB host controller driver.) >>=20 >>=20 >> Don't get me wrong: I *am* in favour of improving the security of EDK2,= and a formally verified loader is potentially useful for that. But I coul= d only consider it a good idea if it can be done without making breaking AP= I changes for which I know I will personally have to maintain workarounds f= or the next ten years. >>=20 >=20 > Well it is just software at the end of the day. We could always wrap any= Industry Standard API (PPI, Protocol, etc) in a library function and let p= eople chose backward compatibility vs better security. The Library Class wo= uld be owned by the edk2 Open Source project so we have more control over i= t.=20 >=20 > The general UEFI (and UEFI PI) is we mostly add new things, and don=E2= =80=99t depreciated things to maintain compatibility. So for example you c= an add a new Protocol to a handle so you have V1 and V2 of a protocol on th= e same handle. An example of this is SimpleTextIn and SimpleTextInEx. Simpl= eTextIn was modeled on the LCD of a serial terminal (our server roots) so i= t did not expose modifier keys, or have an easy way to implement snag keys = so that is why SimpleTextInEx got added for the new functional.=20 >=20 > Thanks, >=20 > Andrew Fish >=20 >> Thanks, >>=20 >> Michael >=20 >=20 >=20 >=20 --Apple-Mail=_762765B2-798C-4F1E-8D08-2DBD8624DF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Some of use also sit on t= he UEFI standards committees so getting changes into the specification is p= ossible with in constraints of what the spec committees find acceptable.&nb= sp;

Thanks,

Andrew Fish

On A= pr 7, 2021, at 3:02 PM, Andrew Fish via groups.io <afish=3Dapple.com@groups.io> wrote:


=
On Apr 7, 2021, at 2:50 PM, Michael Brown <mcb30@ipxe.org> wrote:

On 07/04/2021 22:31, Marvin H=C3=A4user wrote:
Sorry, but I do not see why t= his would be the case. In fact the solution is (temporary) co-existence, as= already is the case with InstallProtocolInterface() and InstallMultiplePro= tocolInterfaces()

InstallMultiple= ProtocolInterfaces() is not a breaking change: the existence of InstallMult= ipleProtocolInterfaces() does not require any change to the way that Instal= lProtocolInterface() is implemented or consumed.

Code written before the invention of InstallMultipleProtocolInterfaces()= will still work now, with no modifications required.

the new APIs would be a supers= et of the old ones, latter can be implemented with former, as also previous= ly done (*2_PROTOCOL instances and shims in e.g. EdkCompatibilityPkg). In s= ome cases, the original protocol interfaces were actually deprecated succes= sfully from the EDK II code base. I would probably offer PCDs to disable th= e expose of the old APIs, so platforms with little need for backwards-compa= tibility and more focus on security can tighten the constraints as they see= fit. Considering the shimmed interfaces for the old protocols/PPIs/... can= be implemented on top of the new public API, and the public API must not c= hange, this code would be practically maintenance-free too in my opinion.

You have to remember that UEFI is = not a monolithic codebase with a single maintaining organisation.  Imp= lementing a *2_PROTOCOL and deprecating the original just causes pain for a= ll the code in the world that is maintained outside of the EDK2 repository,= since that code now has to support *both* the old and new protocols.

As for your ex= ample, I do not believe what is described is "broken". 

To= avoid distraction from that specific example: have a different example. &n= bsp;The EFI_USB_IO_PROTOCOL is fundamentally broken from the perspective of= implementing a network device driver, since there is simply no way to enqu= eue a receive buffer that will wait for the next available packet.  Bu= t this won't get fixed, because it can't get fixed without breaking API com= patibility.

(Incidentally, I've observed UEFI = software in the wild (from Insyde) that works around these UEFI USB specifi= cation flaws by having all of the USB drivers bind to private protocols in = addition to EFI_USB_IO_PROTOCOL, resulting in device drivers that point-bla= nk fail to work with a standards-conformant UEFI USB host controller driver= .)


Don't get me wrong: I *am* i= n favour of improving the security of EDK2, and a formally verified loader = is potentially useful for that.  But I could only consider it a good i= dea if it can be done without making breaking API changes for which I know = I will personally have to maintain workarounds for the next ten years.


Well it is just software at the end of the day. We could always wr= ap any Industry Standard API (PPI, Protocol, etc) in a library function and= let people chose backward compatibility vs better security. The Library Cl= ass would be owned by the edk2 Open Source project so we have more control = over it. 

The general UEFI (and UEFI PI) is we mostly add new things, and don=E2=80= = =99t depreciated things to maintain compatibility. So for example you can = add a new Protocol to a handle so you have V1 and V2 of a protocol on the s= ame handle. An example of this is SimpleTextIn and SimpleTextInEx. SimpleTe= xtIn was modeled on the LCD of a serial terminal (our server roots) so it d= id not expose modifier keys, or have an easy way to implement snag keys so = that is why SimpleTextInEx got added for the new functional. 

Thanks,

Andrew Fish

Thanks,

Michael




--Apple-Mail=_762765B2-798C-4F1E-8D08-2DBD8624DF1F--