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.6231.1617876810012862113 for ; Thu, 08 Apr 2021 03:13:30 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=dYpqCYyD; 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 0C3672400FC for ; Thu, 8 Apr 2021 12:13:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1617876807; bh=nXxoN5i0DNiPAM0Kq5Ro7E5P568lDT428X1PRZkRDzU=; h=Subject:To:From:Date:From; b=dYpqCYyDzJkXb/mgEfQpVkr6C2uW7J/gnzHqhT0qNoXLpYkaO3hfOfD+kS0T78BjI 7DoW66rnt+/CW1iGlQA9kvKGgZyetcsSWWMA291nqyQsdkUvSaCVTgMn23N0nRwbis bIlGH01YTtNKhOXri+/lq308qfJNfH8zW/IBcDJngNfimO1S6VDtuBi7gmqoKRIwt2 1mjBd8UurfgH16ObRl6FzJXbxqWaE6RC5XMOTY+MNzxQJmxQoRq138z+yvPqWfIyDs DU30zztlIXdrF6Vf4V0eNtamw0m3hXy4yPcYGWJL/ZqKaD8p+GsEaMhm8vZTRaR8u6 VI4e0m8dL92vg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGHCT14D7z6tm9; Thu, 8 Apr 2021 12:13:24 +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: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <3bfbdd8d-9417-77f4-6444-5841e685548f@posteo.de> From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: <4710c380-5f54-4bc6-d43c-e372f484a062@posteo.de> Date: Thu, 8 Apr 2021 12:13:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08.04.21 11:55, Michael Brown wrote: > On 08/04/2021 10:41, Marvin H=C3=A4user wrote: >> No, backwards-compatibility will not be broken in the sense that the=20 >> old API is absent or malfunctioning. > > Perfect. :) > >> As I *have* said, I imagine there to be an option (default true) to=20 >> expose both variants. > > Very much less perfect.=C2=A0 The mere existence of such an option=20 > immediately reimposes the burden on external code to support both,=20 > because it opens up the possibility of running on systems where the=20 > option is set to false. One more time, I do not know why any non-platform code would call those=20 APIs. Preferably, they would be private implementation details to me. I=20 understand that you are displeased with your maintenance burden in iPXE,= =20 and I can assure you, you are not alone. We want to support hotswap with= =20 one of our UEFI applications, and I am currently contemplating=20 overriding Uninstall(Multiple)ProtocolInterface(s) to try to ensure=20 security. I hear you, totally. :) >> With default settings, I want the loader to be at the very least=20 >> mostly plug-'n'-play with existing platform drivers and OS loaders=20 >> from the real world. "Mostly" can be clarified further once we have a= =20 >> detailed plan on the changes (and responses to e.g. malformed binary=20 >> issues with iPXE and GNU-EFI). > > Yes; thank you for https://github.com/ipxe/ipxe/pull/313.=C2=A0 It will= =20 > take some time to review. > > As a practical consideration: unless there is a security reason to do=20 > otherwise, you should almost certainly relax the constraints on images= =20 > that your loader will accept, to avoid causing unnecessary end-user=20 > disruption.=C2=A0 What is the *security* reason behind your alignment=20 > requirements (which clearly are not required by any other toolchain,=20 > including those used for signing Secure Boot binaries)? Sorry if that was not clear from the PR, I hoped it was. It's the fact=20 that memory permissions can only be enforced page-wise. So, when two=20 sections with different permissions share a page, at the very least this= =20 page must be applied with relaxed permissions. I do not like relaxing=20 permissions. :) There already is a PCD to relax this, and both iPXE and GNU-EFI images=20 load correctly and securely with it. Just the more relaxed loading is,=20 the more awkward cases need to be considered when applying memory=20 permission attributes. Logically, as the original ELF was correctly=20 aligned segment-wise, the case I described above will not really happen.= =20 Yet it is now the firmware's burden to check all sections with=20 overlapping pages for their attributes and adjust. As, please do not=20 take this offensively, it is "only" iPXE images and the GNU shim loader=20 affected so far, I hope that in due time all images can be updated (the=20 shim can be used for older releases of any distribution as well!) and=20 the constraints be tightened. Yet, of course, this is up to the EDK II=20 maintainers to decide. I furthermore hope that, at some point, both iPXE and shim switch to EDK= =20 II for PE generation to ensure consistency of the binary generation. Best regards, Marvin > > Thanks, > > Michael > > >=20 > >