From: "Michael Brown" <mcb30@ipxe.org>
To: "Marvin Häuser" <mhaeuser@posteo.de>,
devel@edk2.groups.io, "Laszlo Ersek" <lersek@redhat.com>,
"Andrew Fish" <afish@apple.com>,
"Michael Kinney" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [GSoC proposal] Secure Image Loader
Date: Thu, 8 Apr 2021 11:31:53 +0100 [thread overview]
Message-ID: <c9f4aea8-226b-5ae6-d640-bfc0e3919996@ipxe.org> (raw)
In-Reply-To: <4710c380-5f54-4bc6-d43c-e372f484a062@posteo.de>
On 08/04/2021 11:13, Marvin Häuser wrote:
>> Very much less perfect. The mere existence of such an option
>> immediately reimposes the burden on external code to support both,
>> because it opens up the possibility of running on systems where the
>> option is set to false.
>
> One more time, I do not know why any non-platform code would call those
> APIs. Preferably, they would be private implementation details to me.
If you are talking about private APIs that are not even exposed at the
UEFI specification level (i.e. do not have an EFI_XXX_PROTOCOL name and
well-known GUID) then there's no issue.
If they are defined as public APIs (i.e. things that do have an
EFI_XXX_PROTOCOL name and well-known GUID) then you must assume that
some external code, somewhere, will use them.
Which is the case?
>> As a practical consideration: unless there is a security reason to do
>> otherwise, you should almost certainly relax the constraints on images
>> that your loader will accept, to avoid causing unnecessary end-user
>> disruption. What is the *security* reason behind your alignment
>> requirements (which clearly are not required by any other toolchain,
>> 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
> that memory permissions can only be enforced page-wise.
Perfect; thank you. So: the security requirement is that memory
permissions must change only at page boundaries.
> I furthermore hope that, at some point, both iPXE and shim switch to EDK
> II for PE generation to ensure consistency of the binary generation.
There is zero chance of ever pulling the EDK2 build system into iPXE.
It's too large, too painful to use, and doesn't support the full range
of target platforms required (UEFI, BIOS, and Linux userspace).
If EDK2 publishes a tool for converting ELF to PE, and that tool becomes
generally available in Linux distros, then I'd be happy to drop
elf2efi.c and switch to the EDK2 tool about five years from now once
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
practical one.
Thanks,
Michael
prev parent reply other threads:[~2021-04-08 10:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-04 23:01 [GSoC proposal] Secure Image Loader Marvin Häuser
2021-04-06 9:41 ` [edk2-devel] " Nate DeSimone
2021-04-06 10:06 ` Marvin Häuser
2021-04-06 16:16 ` [EXTERNAL] " Bret Barkelew
2021-04-08 11:16 ` Laszlo Ersek
2021-04-08 14:13 ` Andrew Fish
2021-04-08 16:06 ` Marvin Häuser
2021-04-08 16:44 ` Andrew Fish
2021-04-08 17:02 ` Marvin Häuser
2021-04-08 17:39 ` Andrew Fish
2021-04-08 21:07 ` Marvin Häuser
2021-04-08 21:48 ` Andrew Fish
2021-04-08 22:42 ` Michael Brown
2021-04-12 17:22 ` Marvin Häuser
2021-04-12 18:30 ` [EXTERNAL] " Bret Barkelew
2021-04-13 0:19 ` Michael D Kinney
2021-04-13 0:56 ` Nate DeSimone
2021-04-13 7:31 ` Marvin Häuser
2021-04-13 15:05 ` Andrew Fish
2021-04-13 18:04 ` Nate DeSimone
2021-04-13 18:08 ` Michael D Kinney
2021-04-13 18:14 ` Andrew Fish
2021-04-16 7:36 ` Marvin Häuser
2021-04-07 21:05 ` Michael Brown
2021-04-07 21:31 ` Marvin Häuser
2021-04-07 21:50 ` Michael Brown
2021-04-07 22:02 ` Andrew Fish
[not found] ` <1673B28429E5B4FE.4742@groups.io>
2021-04-07 22:10 ` Andrew Fish
2021-04-08 9:04 ` Marvin Häuser
2021-04-08 9:40 ` Michael Brown
2021-04-08 8:53 ` Marvin Häuser
2021-04-08 9:26 ` Michael Brown
2021-04-08 9:41 ` Marvin Häuser
2021-04-08 9:50 ` Marvin Häuser
2021-04-08 9:55 ` Michael Brown
2021-04-08 10:13 ` Marvin Häuser
2021-04-08 10:31 ` Michael Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9f4aea8-226b-5ae6-d640-bfc0e3919996@ipxe.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox