Re: StartImage with Secure Boot on Self-Signed App

["David F." <df7729@gmail.com>]

Thanks, looking forward, can the people on the board dealing with the
specification please consider revising EFI_LOADED_IMAGE_PROTOCOL to
include a new "Flags" field and one of the bits allows StartImage to
start the image even if LoadImage reported a EFI_SECURITY_VIOLATION
was reported.  defined bit name could be #define
EFI_LOADED_IMAGE_PROTOCOL_FLAG_SELF_VALIDATED  0x0000000000000001ULL.
 This provides a clean interface for applications without having to
hack StartImage() with a potential conflict with future changes to the
internal firmware.


On Thu, Sep 7, 2017 at 7:11 PM, Gary Lin <glin@suse.com> wrote:
> On Thu, Sep 07, 2017 at 01:00:03PM -0700, David F. wrote:
>> Hello,
>>
>> What is the proper way to allow running another app that is verified
>> with a self-signed certificate?
>>
>> Example, App1 is signed with one that allows secure boot booting (in
>> firmware) and has a public key embedded in the signed code, App2 is
>> verified by App1 and so is allowed to run, but because the key is not
>> in secure boot firmware, StartImage will not run it (although
>> LoadImage did what it needed to do and already reported the security
>> violation potential).   Do we have to roll our own StartImage?  or is
>> something already in place?  I can't rely on changing an internal
>> private structure field to allow StartImage to work since each
>> firmware platform may change the way it all works, looking for the
>> proper method as designed.
>>
> The major linux distros are using shim(*) to verify the bootloaders and
> kernels signed by ourselves, and shim implements its own StartImage.
>
> If your application is going to be deployed to the newer UEFI, instead
> of using the built-in openssl, you can try EFI_PKCS7_VERIFY_PROTOCOL to
> verify the UEFI images. It will make your application much slimmer and
> easier to maintain.
>
> Cheers,
>
> Gary Lin
>
> (*) https://github.com/rhboot/shim