Actually, even a StartImageEx() would be fine with parameter to allow options.
On Thu, Sep 7, 2017 at 7:51 PM, David F. <df7...@gmail.com> wrote: > 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 <g...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
