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

[Marvin Häuser]

Hey Andrew,

Thank you a lot. One thing I noticed is that part of the quote I did not 
see on the list before, so I marked it below.

Best regards,
Marvin

On 08.04.21 00:10, Andrew Fish wrote:
> Some of use also sit on the UEFI standards committees so getting 
> changes into the specification is possible with in constraints of what 
> the spec committees find acceptable.
>
> Thanks,
>
> Andrew Fish
>
>> On Apr 7, 2021, at 3:02 PM, Andrew Fish via groups.io 
>> <http://groups.io> <afish=apple.com at groups.io 
>> <mailto:afish=apple.com at groups.io>> wrote:
>>
>>
>>
>>> On Apr 7, 2021, at 2:50 PM, Michael Brown <mcb30 at ipxe.org 
>>> <mailto:mcb30 at ipxe.org>> wrote:
>>>
>>> On 07/04/2021 22:31, Marvin Häuser wrote:
>>>> Sorry, but I do not see why this would be the case. In fact the 
>>>> solution is (temporary) co-existence, as already is the case with 
>>>> InstallProtocolInterface() and InstallMultipleProtocolInterfaces()
>>>
>>> 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 new APIs would be a superset of the old ones, latter can be 
>>>> implemented with former, as also previously done (*2_PROTOCOL 
>>>> instances and shims in e.g. EdkCompatibilityPkg). In some cases, 
>>>> the original protocol interfaces were actually deprecated 
>>>> successfully from the EDK II code base. I would probably offer PCDs 
>>>> to disable the expose of the old APIs, so platforms with little 
>>>> need for backwards-compatibility and more focus on security can 
>>>> tighten the constraints as they see fit. Considering the shimmed 
>>>> interfaces for the old protocols/PPIs/... can be implemented on top 
>>>> of the new public API, and the public API must not change, this 
>>>> code would be practically maintenance-free too in my opinion.
>>>
>>> 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.
>>>
>>>> As for your example, I do not believe what is described is "broken".
>>>
>>> To avoid distraction from that specific example: have a different 
>>> example.  The EFI_USB_IO_PROTOCOL is fundamentally broken from the 
>>> perspective of implementing a network device driver, since there is 
>>> simply no way to enqueue a receive buffer that will wait for the 
>>> next available packet.  But this won't get fixed, because it can't 
>>> get fixed without breaking API compatibility.
>>>
>>> (Incidentally, I've observed UEFI software in the wild (from Insyde) 
>>> that works around these UEFI USB specification flaws by having all 
>>> of the USB drivers bind to private protocols in addition to 
>>> EFI_USB_IO_PROTOCOL, resulting in device drivers that point-blank 
>>> fail to work with a standards-conformant UEFI USB host controller 
>>> driver.)
>>>
>>>
>>> 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.
>>>
>>
>> Well it is just software at the end of the day. We could always wrap 
>> any Industry Standard API (PPI, Protocol, etc) in a library function 
>> and let people chose backward compatibility vs better security. The 
>> Library Class would be owned by the edk2 Open Source project so we 
>> have more control over it.
>>
>> The general UEFI (and UEFI PI) is we mostly add new things, and don’t 
>> depreciated things to maintain compatibility. So for example you can 
>> add a new Protocol to a handle so you have V1 and V2 of a protocol on 
>> the same handle. An example of this is SimpleTextIn and 
>> SimpleTextInEx. SimpleTextIn was modeled on the LCD of a serial 
>> terminal (our server roots) so it did not expose modifier keys, or 
>> have an easy way to implement snag keys so that is why SimpleTextInEx 
>> got added for the new functional.
>>
>> Thanks,
>>
>> Andrew Fish

^ Here; +1

>>
>>> Thanks,
>>>
>>> Michael
>>
>>
>>
>> 
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73829): https://edk2.groups.io/g/devel/message/73829
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]
-=-=-=-=-=-=-=-=-=-=-=-