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

["Marvin Häuser" <mhaeuser@posteo.de>]

Good day Michael,

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

As for your example, I do not believe what is described is "broken". 
Ideally, the platform loads all images to have a centralized place for 
the security verification. While we do a very similar thing at 
Acidanthera with our OpenCore bootloader to support Apple Secure Boot, I 
hope you agree that this behaviour is actually a risky hack (now there 
are two points of failure for security verification). Meanwhile, the 
changes I'd like to propose to the current interfaces are mandatory to 
ensure secure parsing of data. Lastly, this sort of API I would not 
expect to be accessed outside of platform code.

Am I missing or overlooking something?

Best regards,
Marvin

On 07.04.21 23:05, Michael Brown wrote:
> On 05/04/2021 00:01, Marvin Häuser wrote:
>> 3. During my initial exploration, I discovered defective PPIs and 
>> protocols (e.g. returning data with no corresponding size) 
>> originating from the UEFI PI and UEFI specifications. Changes need to 
>> be discussed, settled on, and submitted to the UEFI Forum.
>
> Would any of these changes break backwards compatibility?  With the 
> UEFI development model, any protocol that has ever existed in the 
> specification will practically need to always be supported in that 
> form: breaking backwards compatibility is simply not an option.
>
> For example: there is a fundamental design flaw in the LoadImage() and 
> StartImage() API that makes it logically impossible for arbitrary code 
> to install an EFI_LOADED_IMAGE_PROTOCOL instance (see 
> https://github.com/ipxe/ProxyLoaderPkg/#why-is-it-needed for details 
> on this).  But there's zero chance that this design flaw will ever be 
> fixed, because there's no way to eliminate code that relies on the 
> existing LoadImage()/StartImage() APIs.
>
> So: if the formally verified image loader can fit within the 
> constraints of "must not modify any externally exposed APIs" then it 
> sounds like a potentially good idea.  If it requires breaking changes 
> to public APIs then I don't see how it could be integrated in practice.
>
> Thanks,
>
> Michael
>
>
> 
>
>