> On Apr 7, 2021, at 2:50 PM, Michael Brown <mc...@ipxe.org> wrote:
>
> On 07/04/2021 22:31, Marvin Häuser wrote:
>> 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()
>
> InstallMultipleProtocolInterfaces() is not a breaking change: the existence
> of InstallMultipleProtocolInterfaces() does not require any change to the way
> that InstallProtocolInterface() is implemented or consumed.
>
> Code written before the invention of InstallMultipleProtocolInterfaces() will
> still work now, with no modifications required.
>
>> 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.
>
> You have to remember that UEFI is not a monolithic codebase with a single
> maintaining organisation. Implementing a *2_PROTOCOL and deprecating the
> original just causes pain for all the code in the world that is maintained
> outside of the EDK2 repository, since that code now has to support *both* the
> old and new protocols.
>
>> As for your example, I do not believe what is described is "broken".
>
> To avoid distraction from that specific example: have a different example.
> The EFI_USB_IO_PROTOCOL is fundamentally broken from the perspective of
> implementing a network device driver, since there is simply no way to enqueue
> a receive buffer that will wait for the next available packet. But this
> won't get fixed, because it can't get fixed without breaking API
> compatibility.
>
> (Incidentally, I've observed UEFI software in the wild (from Insyde) that
> works around these UEFI USB specification flaws by having all of the USB
> drivers bind to private protocols in addition to EFI_USB_IO_PROTOCOL,
> resulting in device drivers that point-blank fail to work with a
> standards-conformant UEFI USB host controller driver.)
>
>
> Don't get me wrong: I *am* in favour of improving the security of EDK2, and a
> formally verified loader is potentially useful for that. But I could only
> consider it a good idea if it can be done without making breaking API changes
> for which I know I will personally have to maintain workarounds for the next
> ten years.
>
Well it is just software at the end of the day. We could always wrap any
Industry Standard API (PPI, Protocol, etc) in a library function and let people
chose backward compatibility vs better security. The Library Class would be
owned by the edk2 Open Source project so we have more control over it.
The general UEFI (and UEFI PI) is we mostly add new things, and don’t
depreciated things to maintain compatibility. So for example you can add a new
Protocol to a handle so you have V1 and V2 of a protocol on the same handle. An
example of this is SimpleTextIn and SimpleTextInEx. SimpleTextIn was modeled on
the LCD of a serial terminal (our server roots) so it did not expose modifier
keys, or have an easy way to implement snag keys so that is why SimpleTextInEx
got added for the new functional.
Thanks,
Andrew Fish
> Thanks,
>
> Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73803): https://edk2.groups.io/g/devel/message/73803
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]
-=-=-=-=-=-=-=-=-=-=-=-
