public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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

      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