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

[Marvin Häuser]

On 07.04.21 23:50, Michael Brown 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 same is true for the *2_PROTOCOL instances, I do not see how you 
distinct between them. Could you elaborate, please?

>> 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.

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.

>> 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.

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?

> (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.

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. This could both be a separate driver (Thunk, as 
in EdkCompatibilityPkg) or integrated (per PCD). In fact, this does need 
thorough discussion, but my favourite route would be to actually pull 
some things from the PI specification and make them EDK II 
implementation details.

Best regards,
Marvin

>
> Thanks,
>
> Michael



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