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

Thu Apr 8 09:50:53 UTC 2021

Sorry, I accidentally removed an inline comment when sending.

Best regards,
Marvin

On 08.04.21 11:41, Marvin Häuser wrote:
> 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.

It is not about "how much" is EDK II code, but that it is the core. We 
are talking about things like the dispatcher, I have not ever seen it 
modified "lately" (Gigabyte modded AMI CORE_PEI and CORE_DXE with their 
SIO code in Z77, but you get the idea...). I am very well aware of 
issues with "user-facing" things such as input.

>>
>> 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 (#73837): https://edk2.groups.io/g/devel/message/73837
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]
-=-=-=-=-=-=-=-=-=-=-=-