Good day Michael,
Sorry, but I do not see why this would be the case. In fact the solution
is (temporary) co-existence, as already is the case with
InstallProtocolInterface() and InstallMultipleProtocolInterfaces(). As
the new APIs would be a superset of the old ones, latter can be
implemented with former, as also previously done (*2_PROTOCOL instances
and shims in e.g. EdkCompatibilityPkg). In some cases, the original
protocol interfaces were actually deprecated successfully from the EDK
II code base. I would probably offer PCDs to disable the expose of the
old APIs, so platforms with little need for backwards-compatibility and
more focus on security can tighten the constraints as they see fit.
Considering the shimmed interfaces for the old protocols/PPIs/... can be
implemented on top of the new public API, and the public API must not
change, this code would be practically maintenance-free too in my opinion.
As for your example, I do not believe what is described is "broken".
Ideally, the platform loads all images to have a centralized place for
the security verification. While we do a very similar thing at
Acidanthera with our OpenCore bootloader to support Apple Secure Boot, I
hope you agree that this behaviour is actually a risky hack (now there
are two points of failure for security verification). Meanwhile, the
changes I'd like to propose to the current interfaces are mandatory to
ensure secure parsing of data. Lastly, this sort of API I would not
expect to be accessed outside of platform code.
Am I missing or overlooking something?
Best regards,
Marvin
On 07.04.21 23:05, Michael Brown wrote:
On 05/04/2021 00:01, Marvin Häuser wrote:
3. During my initial exploration, I discovered defective PPIs and
protocols (e.g. returning data with no corresponding size)
originating from the UEFI PI and UEFI specifications. Changes need to
be discussed, settled on, and submitted to the UEFI Forum.
Would any of these changes break backwards compatibility? With the
UEFI development model, any protocol that has ever existed in the
specification will practically need to always be supported in that
form: breaking backwards compatibility is simply not an option.
For example: there is a fundamental design flaw in the LoadImage() and
StartImage() API that makes it logically impossible for arbitrary code
to install an EFI_LOADED_IMAGE_PROTOCOL instance (see
https://github.com/ipxe/ProxyLoaderPkg/#why-is-it-needed for details
on this). But there's zero chance that this design flaw will ever be
fixed, because there's no way to eliminate code that relies on the
existing LoadImage()/StartImage() APIs.
So: if the formally verified image loader can fit within the
constraints of "must not modify any externally exposed APIs" then it
sounds like a potentially good idea. If it requires breaking changes
to public APIs then I don't see how it could be integrated in practice.
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73801): https://edk2.groups.io/g/devel/message/73801
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]
-=-=-=-=-=-=-=-=-=-=-=-
