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.web10.48039.1617577317902941512 for ; Sun, 04 Apr 2021 16:01:58 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=P2Q7wg5u; 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 EA3342400FD for ; Mon, 5 Apr 2021 01:01:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617577315; bh=yYm8xdYYlHDCEL52BbICYsgC9GpI831MoOIgMuUgNvE=; h=To:From:Subject:Date:From; b=P2Q7wg5ueefAFIZfUnQu5vSy8sZwOv6+BIJ4GIMkQZbkJFG6mQxYyoTIEVYM0lrjx 1Qqshl3rdk1iMobVL/rXhSXmkHIqN8OH3XAVPjCiGtsOVQNN4x7R7V/+7r3J4IsH6U lfmE0pmfCtxuf9SsdUIipoBpFqNYuX0bueBQ0Oolstw6nMk1q7RUN4H/am7KMMmWcj E763G7MBBPWljv1u/gsS0LRLJAS66da0y1K84QJakacN9v4PFPW1X5vncQYQP1X/oZ 0pcyE6GQbE4J/uwFfF1okWPZhXEwJtr0iijviwAdQ+f72kMxCMjBm87iDPR8EWNZL0 gZ9XqNpRmL69A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FD8S23VGrz6tm6; Mon, 5 Apr 2021 01:01:54 +0200 (CEST) To: devel@edk2.groups.io, Laszlo Ersek , Andrew Fish , Michael Kinney From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Subject: [GSoC proposal] Secure Image Loader Message-ID: Date: Mon, 5 Apr 2021 01:01:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Good day everyone, I'll keep the introduction brief because I've been around for a while=20 now. :) I'm Marvin H=C3=A4user, a third-year Computer Science student from TU=20 Kaiserslautern, Germany. Late last year, my colleague Vitaly from ISP=20 RAS and me introduced a formally verified Image Loader for UEFI usage at=20 ISP RAS Open[1] due to various defects we outlined in the corresponding=20 paper. Thank you once again Laszlo for your *incredible* review work on=20 the publication part. I now want to make an effort to mainline it, preferably as part of the=20 current Google Summer of Code event. To be clear, my internship at ISP=20 RAS has concluded, and while Vitaly will be available for design=20 discussion, he has other priorities at the moment and the practical part=20 will be on me. I have previously submitted a proposal via the GSoC=20 website for your review. 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 take a=20 lot of time to review and integrate. 3. During my initial exploration, I discovered defective PPIs and=20 protocols (e.g. returning data with no corresponding size) originating=20 from the 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=20 appropriate APIs. 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 lot of=20 trust in its correctness and safety. B. All outlined defects that are of critical nature have been fixed=20 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 duplication=20 and potentially unsafe operations. E. Centralising and reduced parse duplication may improve overall boot=20 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 help=20 (incorrectly reported section alignment of an Intel IPXE driver). A fix=20 will be submitted shortly. I. I plan to support PE section permissions, allowing for read-only data=20 segments when enabled. There are likely more points for both lists, but I hope this gives a=20 decent starting point for discussion. What are your thoughts on the=20 matter? I strongly encourage everyone to read the section regarding=20 defects of our publication[2] to better understand the motivation. The=20 vague points above can of course be elaborated in due time, as you see fi= t. Thank you for your time! Best regards, Marvin [1] https://github.com/mhaeuser/ISPRASOpen-SecurePE [2] https://arxiv.org/pdf/2012.05471.pdf