On 08/04/2021 09:53, Marvin Häuser wrote:
On 07.04.21 23:50, Michael Brown wrote:
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 same is true for the *2_PROTOCOL instances, I do not see how you
distinct between them. Could you elaborate, please?
The distinction is very straightforward. If you plan to *remove*
support for the older protocols, then you by definition place a burden
on all externally maintained code to support both protocols. If the
older protocol will continue to be supported then no such burden is created.
This is why I am asking you if your proposed changes require *breaking*
backwards compatibility. You still haven't answered this key question.
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.
I am aware, but actually it's not far from it nowadays. In contrast to
the days of Aptio IV, I believe all big vendors maintain forks of EDK
II. I know the fork nature taints the issue, but also see last quote
comment.
This is empirically not true. Buy a selection of devices in the wild,
and you'll find a huge amount of non-EDK2 code on them.
I would be extremely happy if every vendor just used the EDK2 code: it
would make my life a lot easier. But it's not what happens in the real
world.
I see that there is no EFI_USB_IO2_PROTOCOL instance to argue by. Yet
there are EFI_BLOCK_IO2_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL. Former, in
my opinion, close in nature to your your example, and latter close to
the nature on what I plan to propose. Sorry, but I do not see how what I
suggest has not been done multiple times in the past already.
Please also look at it from an angle of trust. How can I trust the
"secure" advertisements of UEFI / EDK II when the specification
*dictates* the usage of intrinsically insecure APIs?
The consequence for security-critical situations would be to necessarily
abandon UEFI and come up with a new design. In who's interest is this?
Again, we return to the question that you have not yet answered: do your
proposed changes require breaking backwards compatibility?
Please do answer this question: if you're *not* proposing to break the
platform in a way that would prevent older binaries from working without
modification, then we have no disagreement! :)
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.
Sorry, but you seem to have missed my points regarding these concerns,
at least you did not address them I believe. I don't know why you need
to (actively) maintain workarounds for APIs external code has no reason
to use, especially when the legacy implementation would quite literally
be a wrapper function.
<same comment as above>
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73830): https://edk2.groups.io/g/devel/message/73830
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]
-=-=-=-=-=-=-=-=-=-=-=-
