[edk2-devel] [GSoC proposal] Secure Image Loader

[Marvin Häuser]

Well, I assume this is a misunderstanding. I understood your usage of 
"workaround" to be supporting both *_PROTOCOL and *2_PROTOCOL instances. 
Yes, backwards-compatibility will be broken in the sense that the new 
interface will not be compatible with the old interface. No, 
backwards-compatibility will not be broken in the sense that the old API 
is absent or malfunctioning. As I *have* said, I imagine there to be an 
option (default true) to expose both variants. 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).

Best regards,
Marvin

On 08.04.21 11:26, Michael Brown wrote:
> 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 (#73832): https://edk2.groups.io/g/devel/message/73832
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]
-=-=-=-=-=-=-=-=-=-=-=-