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.5479.1617872695895364914 for ; Thu, 08 Apr 2021 02:04:56 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=fWe9iUSy; 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 C17082400FC for ; Thu, 8 Apr 2021 11:04:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617872693; bh=/ZH+7ZKVLZc5MntmEjgpi0E+8xwkKI/MH5BqVIa5IF4=; h=Subject:To:Cc:From:Date:From; b=fWe9iUSysECziTCZETgkjcaVwRUA6g4YXesf8WlfoZsmKUCPCKK4W9e9wWUY7WKu1 1t5uOj3o+h5HwRIVwq2rupPC0yU+rMpH8MxWJy1Tc9Ny+8GzqUNESMLTmczinuqizJ apZbjDghy55Yp6IkFSYc+FSEbyTSvmHwwarxvzZxHJM9LA+/aoxj7IQVCpNu2lpmVj P9CGI3eKy6280FTN1K/93sehYmom3MhF1XsmzkSxV1d1PlYh4d8p8UmDL1rFXeZxkc FsXCPjKLPqBeNZVtDACKeVNDntX9YtbgytQNTcal4v16QWKCMHdNFHO00IahIs4QEb DeTR8Pc9Z8PNQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGFhM48JHz6tmW; Thu, 8 Apr 2021 11:04:51 +0200 (CEST) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: Andrew Fish , edk2-devel-groups-io Cc: Michael Brown , Laszlo Ersek , Mike Kinney References: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <1673B28429E5B4FE.4742@groups.io> <29AA7DA3-6760-4F5B-AD01-0FC334B1C095@apple.com> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: Date: Thu, 8 Apr 2021 11:04:50 +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: <29AA7DA3-6760-4F5B-AD01-0FC334B1C095@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hey Andrew, Thank you a lot. One thing I noticed is that part of the quote I did not= =20 see on the list before, so I marked it below. Best regards, Marvin On 08.04.21 00:10, Andrew Fish wrote: > Some of use also sit on the UEFI standards committees so getting=20 > changes into the specification is possible with in constraints of what= =20 > the spec committees find acceptable. > > Thanks, > > Andrew Fish > >> On Apr 7, 2021, at 3:02 PM, Andrew Fish via groups.io=20 >> > > wrote: >> >> >> >>> On Apr 7, 2021, at 2:50 PM, 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=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 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,=20 >>>> the original protocol interfaces were actually deprecated=20 >>>> successfully from the EDK II code base. I would probably offer PCDs= =20 >>>> to disable the expose of the old APIs, so platforms with little=20 >>>> need for backwards-compatibility and more focus on security can=20 >>>> tighten the constraints as they see fit. Considering the shimmed=20 >>>> interfaces for the old protocols/PPIs/... can be implemented on top= =20 >>>> of the new public API, and the public API must not change, this=20 >>>> code would be 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=A0Implementing 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. >>> >>>> As for your example, I do not believe what is described is "broken". >>> >>> To avoid distraction from that specific example: have a different=20 >>> example. =C2=A0The EFI_USB_IO_PROTOCOL is fundamentally broken from th= e=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=20 >>> next available packet. =C2=A0But this won't get fixed, because it can'= t=20 >>> get fixed without breaking API compatibility. >>> >>> (Incidentally, I've observed UEFI software in the wild (from Insyde)= =20 >>> that works around these UEFI USB specification flaws by having all=20 >>> of the USB drivers bind to private protocols in addition to=20 >>> EFI_USB_IO_PROTOCOL, resulting in device drivers that point-blank=20 >>> fail to work with a standards-conformant UEFI USB host controller=20 >>> 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.= =20 >>> =C2=A0But I could only consider it a good idea if it can be done witho= ut=20 >>> making breaking API changes for which I know I will personally have=20 >>> to maintain workarounds for the next ten years. >>> >> >> Well it is just software at the end of the day. We could always wrap=20 >> any Industry Standard API (PPI, Protocol, etc) in a library function=20 >> and let people chose backward compatibility vs better security. The=20 >> Library Class would be owned by the edk2 Open Source project so we=20 >> have more control over it. >> >> The general UEFI (and UEFI PI) is we mostly add new things, and don=E2= =80=99t=20 >> depreciated things to maintain compatibility. So for example you can=20 >> add a new Protocol to a handle so you have V1 and V2 of a protocol on= =20 >> the same handle. An example of this is SimpleTextIn and=20 >> SimpleTextInEx. SimpleTextIn was modeled on the LCD of a serial=20 >> terminal (our server roots) so it did not expose modifier keys, or=20 >> have an easy way to implement snag keys so that is why SimpleTextInEx= =20 >> got added for the new functional. >> >> Thanks, >> >> Andrew Fish ^ Here; +1 >> >>> Thanks, >>> >>> Michael >> >> >> >>=20 >