On 08.04.21 11:55, Michael Brown wrote:
On 08/04/2021 10:41, Marvin Häuser wrote:
No, backwards-compatibility will not be broken in the sense that the
old API is absent or malfunctioning.
Perfect. :)
As I *have* said, I imagine there to be an option (default true) to
expose both variants.
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. I
understand that you are displeased with your maintenance burden in iPXE,
and I can assure you, you are not alone. We want to support hotswap with
one of our UEFI applications, and I am currently contemplating
overriding Uninstall(Multiple)ProtocolInterface(s) to try to ensure
security. I hear you, totally. :)
With default settings, I want the loader to be at the very least
mostly plug-'n'-play with existing platform drivers and OS loaders
from the real world. "Mostly" can be clarified further once we have a
detailed plan on the changes (and responses to e.g. malformed binary
issues with iPXE and GNU-EFI).
Yes; thank you for https://github.com/ipxe/ipxe/pull/313. It will
take some time to review.
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. So, when two
sections with different permissions share a page, at the very least this
page must be applied with relaxed permissions. I do not like relaxing
permissions. :)
There already is a PCD to relax this, and both iPXE and GNU-EFI images
load correctly and securely with it. Just the more relaxed loading is,
the more awkward cases need to be considered when applying memory
permission attributes. Logically, as the original ELF was correctly
aligned segment-wise, the case I described above will not really happen.
Yet it is now the firmware's burden to check all sections with
overlapping pages for their attributes and adjust. As, please do not
take this offensively, it is "only" iPXE images and the GNU shim loader
affected so far, I hope that in due time all images can be updated (the
shim can be used for older releases of any distribution as well!) and
the constraints be tightened. Yet, of course, this is up to the EDK II
maintainers to decide.
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.
Best regards,
Marvin
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73840): https://edk2.groups.io/g/devel/message/73840
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]
-=-=-=-=-=-=-=-=-=-=-=-
