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.6063.1617877916987247907 for ; Thu, 08 Apr 2021 03:31:58 -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 4DBDA441E4; Thu, 8 Apr 2021 10:31:53 +0000 (UTC) Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader To: =?UTF-8?Q?Marvin_H=c3=a4user?= , devel@edk2.groups.io, Laszlo Ersek , Andrew Fish , Michael Kinney References: <471e56d3-934f-6bb3-52d7-4892f6a75509@ipxe.org> <3bfbdd8d-9417-77f4-6444-5841e685548f@posteo.de> <4710c380-5f54-4bc6-d43c-e372f484a062@posteo.de> From: "Michael Brown" Message-ID: Date: Thu, 8 Apr 2021 11:31:53 +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: <4710c380-5f54-4bc6-d43c-e372f484a062@posteo.de> 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 08/04/2021 11:13, Marvin H=C3=A4user wrote: >> 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. >=20 > 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. If you are talking about private APIs that are not even exposed at the=20 UEFI specification level (i.e. do not have an EFI_XXX_PROTOCOL name and=20 well-known GUID) then there's no issue. If they are defined as public APIs (i.e. things that do have an=20 EFI_XXX_PROTOCOL name and well-known GUID) then you must assume that=20 some external code, somewhere, will use them. Which is the case? >> 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)? >=20 > 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. Perfect; thank you. So: the security requirement is that memory=20 permissions must change only at page boundaries. > I furthermore hope that, at some point, both iPXE and shim switch to ED= K=20 > II for PE generation to ensure consistency of the binary generation. There is zero chance of ever pulling the EDK2 build system into iPXE.=20 It's too large, too painful to use, and doesn't support the full range=20 of target platforms required (UEFI, BIOS, and Linux userspace). If EDK2 publishes a tool for converting ELF to PE, and that tool becomes=20 generally available in Linux distros, then I'd be happy to drop=20 elf2efi.c and switch to the EDK2 tool about five years from now once=20 it's safe to assume its existence on any viable build platform. This may not be quite the answer you were hoping for, but it's the only=20 practical one. Thanks, Michael