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

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

On 08.04.21 11:55, Michael Brown wrote:
> On 08/04/2021 10:41, Marvin Häuser wrote:
>> No, backwards-compatibility will not be broken in the sense that the 
>> old API is absent or malfunctioning.
>
> Perfect. :)
>
>> As I *have* said, I imagine there to be an option (default true) to 
>> expose both variants.
>
> Very much less perfect.  The mere existence of such an option 
> immediately reimposes the burden on external code to support both, 
> because it opens up the possibility of running on systems where the 
> option is set to false.

One more time, I do not know why any non-platform code would call those 
APIs. Preferably, they would be private implementation details to me. I 
understand that you are displeased with your maintenance burden in iPXE, 
and I can assure you, you are not alone. We want to support hotswap with 
one of our UEFI applications, and I am currently contemplating 
overriding Uninstall(Multiple)ProtocolInterface(s) to try to ensure 
security. I hear you, totally. :)

>> 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).
>
> Yes; thank you for https://github.com/ipxe/ipxe/pull/313.  It will 
> take some time to review.
>
> As a practical consideration: unless there is a security reason to do 
> otherwise, you should almost certainly relax the constraints on images 
> that your loader will accept, to avoid causing unnecessary end-user 
> disruption.  What is the *security* reason behind your alignment 
> requirements (which clearly are not required by any other toolchain, 
> including those used for signing Secure Boot binaries)?

Sorry if that was not clear from the PR, I hoped it was. It's the fact 
that memory permissions can only be enforced page-wise. So, when two 
sections with different permissions share a page, at the very least this 
page must be applied with relaxed permissions. I do not like relaxing 
permissions. :)

There already is a PCD to relax this, and both iPXE and GNU-EFI images 
load correctly and securely with it. Just the more relaxed loading is, 
the more awkward cases need to be considered when applying memory 
permission attributes. Logically, as the original ELF was correctly 
aligned segment-wise, the case I described above will not really happen. 
Yet it is now the firmware's burden to check all sections with 
overlapping pages for their attributes and adjust. As, please do not 
take this offensively, it is "only" iPXE images and the GNU shim loader 
affected so far, I hope that in due time all images can be updated (the 
shim can be used for older releases of any distribution as well!) and 
the constraints be tightened. Yet, of course, this is up to the EDK II 
maintainers to decide.

I furthermore hope that, at some point, both iPXE and shim switch to EDK 
II for PE generation to ensure consistency of the binary generation.

Best regards,
Marvin

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