From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.apple.com [17.179.253.34]) by mx.groups.io with SMTP id smtpd.web12.1177.1618337655845330754 for ; Tue, 13 Apr 2021 11:14:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=dqJLxyCq; spf=pass (domain: apple.com, ip: 17.179.253.34, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13DI8eoQ012333; Tue, 13 Apr 2021 11:14:15 -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=IW4g2g4T/1xC37kGgY4Jnfr0sEqfy8ZnrnxK9QRB6ds=; b=dqJLxyCqzhRLj2VZQBwEz0S5DPRQQR9c4jNPJcYrQZ2jthF/0kl0ChZT1iHuENisI82U PztvEf0rhRReV548+ePbrLjiD8JYHCclF8/hyGnY8PXmmVe9eZB+YMJoTwoxXSGSzw/6 514hqbHHn9Z4GEhtt9baOOQOgqBvXS83hA8KTauS98KJzvn3RlWKoXsBjLt7s6SnTzsJ nEXHv5uMGJpAMWtcS3uX4hl5nYbwwIDOrzDbp/2DVmaVenOrWfVXrAuk/VAEkSYNrkgb E+N/jYyR9QBjC0WEWo81XdiYlLnpSKvL9d0UKP038jU59aX+ijILuPObjpK59J9vCHtR 5g== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 37u9kcbnmk-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Apr 2021 11:14:15 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) 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 <0QRI00MS8LBQI240@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 13 Apr 2021 11:14:14 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRI00H00KWWLJ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 11:14:14 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-Va-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-Va-CD: 0 X-Va-ID: 5ea539b5-6cec-4461-b12c-d5d41bd94904 X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: 6a647426990f4fc248f9d9721cb161d4 X-V-R-CD: 0ee6c4a95a2e1248d03989c9ba42fe98 X-V-CD: 0 X-V-ID: 2d31aec9-9c22-49d3-84f1-4b14680258e0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-13_12:2021-04-13,2021-04-13 signatures=0 Received: from [17.235.26.197] (unknown [17.235.26.197]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRI00Q9ZLBOA300@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 11:14:13 -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: Date: Tue, 13 Apr 2021 11:14:12 -0700 Cc: =?utf-8?Q?Marvin_H=C3=A4user?= , Mike Kinney , "devel@edk2.groups.io" , Laszlo Ersek Message-id: References: <055bcd6f-c055-25a8-f258-6581ccbbd591@posteo.de> <4fa3c0fc-8865-447e-96ec-7286b0fd9a7f@posteo.de> To: "Desimone, Nathaniel L" 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-13_12:2021-04-13,2021-04-13 signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 13, 2021, at 11:04 AM, Desimone, Nathaniel L wrote: >=20 > Hi Marvin, >=20 > What Mike and I were thinking is having a FixedAtBuildPcd which chooses = whether to use the new loader or the old loader at compile time. We were al= so thinking the same thing of shimming the old loader into the new interfac= e. I completely agree with you that it is unlikely the new loader is "broke= n"... it is more likely that broken images exist out in the world somewhere= and that we won't know that they are broken until someone tries to build t= heir system's firmware with the new loader included. Once the broken images= are found, it can take some time to get them fixed. A lot of times they co= me from outside vendors and the source code for those binaries is not readi= ly available. Because of that, there may be a need to fallback to the old l= oader in the interim period while a fixed binary is being acquired. >=20 > This could become very difficult for OpROMs on PCIe add-in cards since t= hey are stored on a separate device rom and most of the time are completely= non-upgradable. We should think about how we can handle the case where we = find an old graphics or network card built in 2014 that has a UEFI OpROM th= at contains a broken PE/COFF header which cannot be fixed. >=20 Don=E2=80=99t forget Thunderbolt dongles, docks, and devices.=20 Thanks, Andrew Fish > Thanks, > Nate >=20 > -----Original Message----- > From: Marvin H=C3=A4user =20 > Sent: Tuesday, April 13, 2021 12:32 AM > To: Desimone, Nathaniel L > Cc: Kinney, Michael D ; devel@edk2.groups.io= ; Laszlo Ersek ; Andrew Fish > Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader >=20 > Hey Mike, > Hey Nate, >=20 > I'm not 100 % sure I get what you mean. The interfaces of the two soluti= ons are not compatible (however I could write wrapper code to shim the old = into the new I suppose?), so on-the-fly switching between the two would be = inconvenient. I do plan to keep the old library around and guard it with th= e deprecated interfaces macro, for out-of-tree code, however. The new libra= ry interfaces will probably be something like PeCoffLib2, PeCoffDebugLib2, = maybe more. >=20 > I'm also not sure what on-the-fly switching would accomplish, as testing= with the old loader allows broken images to be loaded, i.e. just because s= omething "works" with the old code but not the new, it doesn't mean that th= e new code is broken. >=20 > Instead of debugging with two libraries, I rather want to make sure this= thing is rock-solid before even sending out the patches. For this I would = like to build a small EFI file database to parse and load from userland, ch= ecking for image acceptance and memory safety. This would include several v= ersions of Windows and macOS bootloaders, Option ROMs (NVIDIA and AMD GOP, = iPXE), tools (memtest), and so on. If you have anything you want to have es= pecially tested, please let me know. >=20 > Best regards, > Marvin >=20 > 13.04.2021 02:56:22 Desimone, Nathaniel L : >=20 >> Hi Marvin, >>=20 >> I agree with Mike K that having both the new strict loader and the old = loader co-exist for some time may be the best option. That will give the ec= osystem time to test the new loader and correct any issues that arise from = its introduction. >>=20 >> Best Regards, >> Nate >>=20 >> -----Original Message----- >> From: Kinney, Michael D >> Sent: Monday, April 12, 2021 5:20 PM >> To: Marvin H=C3=A4user ; devel@edk2.groups.io;=20 >> Desimone, Nathaniel L ; Laszlo Ersek=20 >> ; Andrew Fish ; Kinney, Michael D= =20 >> >> Subject: RE: [edk2-devel] [GSoC proposal] Secure Image Loader >>=20 >> Hi Marvin, >>=20 >> If it has not already been considered, one option is to submit a new in= stance of the PE/COFF Library, so both the existing one and the new one are= available to the ecosystem. >>=20 >> This allows you to be successful in submitting code outlined in your pr= oposal and gives the ecosystem time to evaluate and decide when/if to switc= h from the old to the new. >>=20 >> Mike >>=20 >>> -----Original Message----- >>> From: Marvin H=C3=A4user >>> Sent: Monday, April 12, 2021 10:22 AM >>> To: devel@edk2.groups.io; Desimone, Nathaniel L=20 >>> ; Laszlo Ersek ;=20 >>> Andrew Fish ; Kinney, Michael D=20 >>> >>> Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader >>>=20 >>> Good day Nate, >>>=20 >>> As you seem to be mostly in charge of the GSoC side of things, I=20 >>> direct this at you, but of course everyone is welcome to comment. >>>=20 >>> I think I finished my first round of investigations just in time for= =20 >>> the deadline. You can find a list of BZs attached[1]. Please note=20 >>> that >>> 1) some are declared security issues and may not be publicly=20 >>> accessible, and 2) that this list is far from complete. I only added= =20 >>> items that are >>> a) not implicitly fixed by "simply" deploying the new Image Loader >>> (*some* important prerequisites are listed), and b) I am confident=20 >>> are actual issues (or things to consider) I believe to know how to app= roach. >>>=20 >>> I have taken notes about more things, e.g. the existence of the=20 >>> security architectural protocols, which I could not find a rationale= =20 >>> for. I can prepare something for this matter, but it really needs an= =20 >>> active discussion with some of the core people. I'm not sure delayed= =20 >>> e-mail discussion is going to be enough, but there is an official IRC= =20 >>> I suppose. :) I hope we can work something out for this. >>>=20 >>> I also hope this makes it clearer why I don't believe that we need to= =20 >>> "fill" 10 weeks, but rather the opposite. This is not a matter of=20 >>> replacing a library instance, but the whole surrounding ecosystem=20 >>> needs to follow for the changes to make sense. And as I tried to make= =20 >>> clear in my discussion with Michael Brown, I am not keen on=20 >>> preserving backwards-compatibility with platform code (i.e. PEI, DXE,= =20 >>> things we consider "internal"), as most of it should be controlled by= =20 >>> EDK II already. This of course does *not* include user code (OROMs,=20 >>> bootloaders, ...), for which I want to provide the *option* to lock=20 >>> some of them out for security, but with sane defaults that will=20 >>> ensure good compatibility. >>>=20 >>> I'd like to thank Michael Brown for his cooperation and support,=20 >>> because we recently landed changes in iPXE to allow for the strictest= =20 >>> image format and permission constraints currently possible[2]. >>>=20 >>> I will have to rework the submitted proposal to reflect the new=20 >>> knowledge. To be honest, seeing how the BZs kept rolling in, I am not= =20 >>> convinced an amazing amount of mainlining can be accomplished during= =20 >>> the >>> 10 weeks. It may have to suffice to have a publicly accessible=20 >>> prototype (e.g. OVMF) and a subset of the planned patches on the list. >>> I hope you can manage to provide some feedback before the deadline pas= ses tomorrow. >>>=20 >>> Thank you in advance! >>>=20 >>> Best regards, >>> Marvin >>>=20 >>> [1] >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3315 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3316 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3317 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3318 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3319 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3320 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3321 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3322 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3323 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3324 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3326 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3327 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3328 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3329 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3330 >>> https://bugzilla.tianocore.org/show_bug.cgi?id=3D3331 >>>=20 >>> [2] https://github.com/ipxe/ipxe/pull/313 >>>=20 >>> On 06.04.21 11:41, Nate DeSimone wrote: >>>> Hi Marvin, >>>>=20 >>>> Great to meet you and welcome back! Glad you hear you are=20 >>>> interested! Completing a formal verification of a PE/COFF >>> loader is certainly impressive. Was this done with some sort of=20 >>> automated theorem proving? It would seem a rather arduous task doing= =20 >>> an inductive proof for an algorithm like that by hand! I completely ag= ree with you that getting a formally verified PE/COFF loader into mainline = is undoubtably valuable and would pay security dividends for years to come. >>>>=20 >>>> Admittedly, this is an area of computer science that I don't have a= =20 >>>> great deal of experience with. The furthest I have >>> gone on this topic is writing out proofs for simple algorithms on=20 >>> exams in my Algorithms class in college. Regardless you have a much=20 >>> better idea of what the current status is of the work that you and=20 >>> Vitaly have done. I guess my only question is do you think there is=20 >>> sufficient work remaining to fill the 10 week GSoC development window?= Certainly we can use some of that time to perform the code reviews you men= tion and write up formal ECRs for the UEFI spec changes that you believe ar= e needed. >>>>=20 >>>> Thank you for sending the application and alerting us to the great=20 >>>> work you and Vitaly have done! I'll read your paper >>> more closely and come back with any questions I still have. >>>>=20 >>>> With Best Regards, >>>> Nate >>>>=20 >>>>> -----Original Message----- >>>>> From: devel@edk2.groups.io On Behalf Of=20 >>>>> Marvin H=C3=A4user >>>>> Sent: Sunday, April 4, 2021 4:02 PM >>>>> To: devel@edk2.groups.io; Laszlo Ersek ; Andrew= =20 >>>>> Fish ; Kinney, Michael D=20 >>>>> >>>>> Subject: [edk2-devel] [GSoC proposal] Secure Image Loader >>>>>=20 >>>>> Good day everyone, >>>>>=20 >>>>> I'll keep the introduction brief because I've been around for a=20 >>>>> while now. :) I'm Marvin H=C3=A4user, a third-year Computer Science= =20 >>>>> student from TU Kaiserslautern, Germany. Late last year, my=20 >>>>> colleague Vitaly from ISP RAS and me introduced a formally verified= =20 >>>>> Image Loader for UEFI usage at ISP RAS Open[1] due to various=20 >>>>> defects we outlined in the corresponding paper. Thank you once again= Laszlo for your *incredible* review work on the publication part. >>>>>=20 >>>>> I now want to make an effort to mainline it, preferably as part of= =20 >>>>> the current Google Summer of Code event. To be clear, my internship= =20 >>>>> at ISP RAS has concluded, and while Vitaly will be available for=20 >>>>> design discussion, he has other priorities at the moment and the=20 >>>>> practical part will be on me. I have previously submitted a proposal= via the GSoC website for your review. >>>>>=20 >>>>> There are many things to consider: >>>>> 1. The Image Loader is a core component, and there needs to be a=20 >>>>> significant level of quality and security assurance. >>>>> 2. Being consumed by many packages, the proposed patch set will=20 >>>>> take a lot of time to review and integrate. >>>>> 3. During my initial exploration, I discovered defective PPIs and pr= otocols (e.g. >>>>> returning data with no corresponding size) originating from the=20 >>>>> UEFI PI and UEFI specifications. Changes need to be discussed,=20 >>>>> settled on, and submitted to the UEFI Forum. >>>>> 4. Some UEFI APIs like the Security Architecture protocols are=20 >>>>> inconveniently abstract, see 5. >>>>> 5. Some of the current code does not use the existing context, or=20 >>>>> accesses it outside of the exposed APIs. The control flow of the=20 >>>>> dispatchers may need to be adapted to make the context available to = appropriate APIs. >>>>>=20 >>>>> But obviously there are not only unpleasant considerations: >>>>> A. The Image Loader is mostly formally verified, and only very few= =20 >>>>> changes will be required from the last proven state. This gives a=20 >>>>> lot of trust in its correctness and safety. >>>>> B. All outlined defects that are of critical nature have been fixed = successfully. >>>>> C. The Image Loader has been tested with real-world code loading=20 >>>>> real-world OSes on thousands of machines in the past few months,=20 >>>>> including rejecting malformed images (configurable by PCD). >>>>> D. The new APIs will centralise everything PE, reducing code=20 >>>>> duplication and potentially unsafe operations. >>>>> E. Centralising and reduced parse duplication may improve overall=20 >>>>> boot performance. >>>>> F. The code has been coverage-tested to not contain dead code. >>>>> G. The code has been fuzz-tested including sanitizers to not invoke= =20 >>>>> undefined behaviour. >>>>> H. I already managed to identify a malformed image in OVMF with its= =20 >>>>> help (incorrectly reported section alignment of an Intel IPXE=20 >>>>> driver). A fix will be submitted shortly. >>>>> I. I plan to support PE section permissions, allowing for read-only= =20 >>>>> data segments when enabled. >>>>>=20 >>>>> There are likely more points for both lists, but I hope this gives= =20 >>>>> a decent starting point for discussion. What are your thoughts on=20 >>>>> the matter? I strongly encourage everyone to read the section=20 >>>>> regarding defects of our publication[2] to better understand the=20 >>>>> motivation. The vague points above can of course be elaborated in du= e time, as you see fit. >>>>>=20 >>>>> Thank you for your time! >>>>>=20 >>>>> Best regards, >>>>> Marvin >>>>>=20 >>>>>=20 >>>>> [1] https://github.com/mhaeuser/ISPRASOpen-SecurePE >>>>> [2] https://arxiv.org/pdf/2012.05471.pdf >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20