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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
