[edk2-devel] [GSoC proposal] Secure Image Loader

Michael Brown mcb30 at ipxe.org
Thu Apr 8 10:31:53 UTC 2021


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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73841): https://edk2.groups.io/g/devel/message/73841
Mute This Topic: https://groups.io/mt/81853302/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-






More information about the edk2-devel-archive mailing list