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

["Michael Brown" <mcb30@ipxe.org>]

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