[edk2-devel] [GSoC proposal] Secure Image Loader
Michael Brown
mcb30 at ipxe.org
Thu Apr 8 09:26:27 UTC 2021
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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list