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.web12.786.1617831102289104883 for ; Wed, 07 Apr 2021 14:31:43 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=GEKffwso; 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 E8B98240103 for ; Wed, 7 Apr 2021 23:31:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617831097; bh=PuglXpUPrNpWN7bR88Wfp4KmmK8c8lDgWLxdPYS1Xq0=; h=Subject:To:From:Date:From; b=GEKffwso34B9QwihbEuekvMFpLG/XdZkX52Fiqz3cqcJQkGVRd29+oWr8ZovTyyB6 wYRgEXxGYtA22lVe0nr+AAicyMeVXxMzup8FnyV47K78uzjLAhxKAZHf4OrKJYPYQl KOU/qkFHOQ0SKLD86nGaDpZnaZh6/ZqzU6ZLDoSw7xFi7sQhviTK8QidwXrZELFSSV Ld6p7X3H0wQubm5RuCRXsGB1wBVvb3AUVWFxZhwmp8HbLLjD3qU1fSdKc+rpryKbbo FnB9S+W9jKG3fI4izY9v0x6/dV6IW77hYP9tRQfSs+TWOsSxNE7+fzRIbG0/XWWn9G YE2JLce2OAgXQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FFyJS689Hz9rxM; Wed, 7 Apr 2021 23:31:36 +0200 (CEST) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: devel@edk2.groups.io, mcb30@ipxe.org, Laszlo Ersek , Andrew Fish , Michael Kinney References: From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: Date: Wed, 7 Apr 2021 23:31:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Good day Michael, Sorry, but I do not see why this would be the case. In fact the solution= =20 is (temporary) co-existence, as already is the case with=20 InstallProtocolInterface() and InstallMultipleProtocolInterfaces(). As=20 the new APIs would be a superset of the old ones, latter can be=20 implemented with former, as also previously done (*2_PROTOCOL instances=20 and shims in e.g. EdkCompatibilityPkg). In some cases, the original=20 protocol interfaces were actually deprecated successfully from the EDK=20 II code base. I would probably offer PCDs to disable the expose of the=20 old APIs, so platforms with little need for backwards-compatibility and=20 more focus on security can tighten the constraints as they see fit.=20 Considering the shimmed interfaces for the old protocols/PPIs/... can be= =20 implemented on top of the new public API, and the public API must not=20 change, this code would be practically maintenance-free too in my opinion. As for your example, I do not believe what is described is "broken".=20 Ideally, the platform loads all images to have a centralized place for=20 the security verification. While we do a very similar thing at=20 Acidanthera with our OpenCore bootloader to support Apple Secure Boot, I= =20 hope you agree that this behaviour is actually a risky hack (now there=20 are two points of failure for security verification). Meanwhile, the=20 changes I'd like to propose to the current interfaces are mandatory to=20 ensure secure parsing of data. Lastly, this sort of API I would not=20 expect to be accessed outside of platform code. Am I missing or overlooking something? Best regards, Marvin On 07.04.21 23:05, Michael Brown wrote: > 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)=20 >> originating from the UEFI PI and UEFI specifications. Changes need to= =20 >> be discussed, settled on, and submitted to the UEFI Forum. > > Would any of these changes break backwards compatibility?=C2=A0 With the= = =20 > UEFI development model, any protocol that has ever existed in the=20 > specification will practically need to always be supported in that=20 > form: 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=20 > on this).=C2=A0 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=20 > constraints of "must not modify any externally exposed APIs" then it=20 > sounds like a potentially good idea.=C2=A0 If it requires breaking chang= es=20 > to public APIs then I don't see how it could be integrated in practice. > > Thanks, > > Michael > > >=20 > >