From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web09.417.1617829531451584443 for ; Wed, 07 Apr 2021 14:05:32 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:72b3:d5ff:feb1:e101]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 8FEE144286; Wed, 7 Apr 2021 21:05:27 +0000 (UTC) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: devel@edk2.groups.io, mhaeuser@posteo.de, Laszlo Ersek , Andrew Fish , Michael Kinney References: From: "Michael Brown" Message-ID: Date: Wed, 7 Apr 2021 22:05:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/04/2021 00:01, Marvin H=C3=A4user wrote: > 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. Would any of these changes break backwards compatibility? With the UEFI=20 development model, any protocol that has ever existed in the=20 specification will practically need to always be supported in that form:=20 breaking backwards compatibility is simply not an option. For example: there is a fundamental design flaw in the LoadImage() and=20 StartImage() API that makes it logically impossible for arbitrary code=20 to install an EFI_LOADED_IMAGE_PROTOCOL instance (see=20 https://github.com/ipxe/ProxyLoaderPkg/#why-is-it-needed for details on=20 this). But there's zero chance that this design flaw will ever be=20 fixed, because there's no way to eliminate code that relies on the=20 existing LoadImage()/StartImage() APIs. So: if the formally verified image loader can fit within the constraints=20 of "must not modify any externally exposed APIs" then it sounds like a=20 potentially good idea. If it requires breaking changes to public APIs=20 then I don't see how it could be integrated in practice. Thanks, Michael