From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web08.186.1617832971505264861 for ; Wed, 07 Apr 2021 15:02:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=VSocNTFK; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 137LwZPM052960; Wed, 7 Apr 2021 15:02:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ms4tzWjUoyzMHGfLMUR43a6M1OflfTe3U6n961fJcS4=; b=VSocNTFKZZ+rRBofwTotDXLs+pz8NYOFRQkSLz9OyasYgiZRTqRYgVmOLCSzGwRqrZwp L7ru3QFArI5MwFP5xdjgekyKIPq0fsKsdI/1o5WuO0A8X/f6l/ctSx3Vpbjr/NihVthB v6xCkSZxVHj6VJQSzrabt5wJHFowDKU3a9C2Hdx/25SRKx98WNug+2VqrGR/5d2df+N2 Pg76NoNuyXxgX4A/Ovu2ItSZzC1AiiDpFBJBM7Yy7ByXOOcmDeLlhk/YZBwT/frvQP56 RNgEokfw9qObjSl4hhtvDbD3XCupd4d72Ni5Rqniv8axTC51lEwOP6T4VnyRuMUPgkTq Tg== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 37rvfc3hrf-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Apr 2021 15:02:50 -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-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QR700IBIRWPTQ50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 07 Apr 2021 15:02:49 -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 <0QR700X00RUY4F00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Apr 2021 15:02:49 -0700 (PDT) X-Va-A: X-Va-T-CD: 6c7192f7554cb912fd7c9cbc31560ee2 X-Va-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-Va-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-Va-CD: 0 X-Va-ID: c97eb573-b216-430f-8c97-cf05db17dcca X-V-A: X-V-T-CD: 6c7192f7554cb912fd7c9cbc31560ee2 X-V-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-V-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-V-CD: 0 X-V-ID: d7b64364-26a2-48ae-81bb-4d2e83e31b54 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 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 <0QR700T5GRWONJ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Apr 2021 15:02:49 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader From: "Andrew Fish" In-reply-to: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> Date: Wed, 07 Apr 2021 15:02:47 -0700 Cc: =?utf-8?Q?Marvin_H=C3=A4user?= , devel@edk2.groups.io, Laszlo Ersek , Mike Kinney Message-id: <22B1C414-E85C-460A-BFF0-123835899069@apple.com> References: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> To: Michael Brown 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: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > 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 = solution is (temporary) co-existence, as already is the case with = InstallProtocolInterface() and InstallMultipleProtocolInterfaces() >=20 > InstallMultipleProtocolInterfaces() is not a breaking change: the = existence 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 = implemented with former, as also previously done (*2_PROTOCOL instances = and shims in e.g. EdkCompatibilityPkg). In some cases, the original = protocol interfaces were actually deprecated successfully from the EDK = II code base. I would probably offer PCDs to disable the expose of the = old APIs, so platforms with 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 maintenance-free too in my = opinion. >=20 > You have to remember that UEFI is not a monolithic codebase with a = single maintaining organisation. Implementing a *2_PROTOCOL and = deprecating the original just causes pain for all 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. >=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 = example. The EFI_USB_IO_PROTOCOL is fundamentally broken from the = perspective of implementing a network device driver, since there is = simply no way to enqueue a receive buffer that will wait for the next = available packet. But this won't get fixed, because it can't get fixed = without breaking API compatibility. >=20 > (Incidentally, I've observed UEFI software in the wild (from Insyde) = that 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, resulting in device drivers that point-blank fail = to work with a standards-conformant 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 could only consider it a good idea 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. >=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 = people chose backward compatibility vs better security. The Library = Class would be owned by the edk2 Open Source project so we have more = control over it.=20 The general UEFI (and UEFI PI) is we mostly add new things, and don=E2=80=99= t 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 same handle. An example of this is SimpleTextIn and SimpleTextInEx. = SimpleTextIn was modeled on the LCD of a serial terminal (our server = roots) so it 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 Thanks, Andrew Fish > Thanks, >=20 > Michael