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

[Michael Brown]

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.

Thanks,

Michael


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