Re: StartImage with Secure Boot on Self-Signed App

["Gao, Liming" <liming.gao@intel.com>]

David:
  PI Security2 Architectural Protocol can be used to verify PE image. It wraps Trusted Computing Group (TCG) measured boot and UEFI  Secure boot. But, you can't base on it to know the wrong return status from TCG measurement or image verification. 

Thanks
Liming
>-----Original Message-----
>From: David F. [mailto:df7729@gmail.com]
>Sent: Friday, October 06, 2017 8:28 AM
>To: Gao, Liming <liming.gao@intel.com>
>Cc: Gary Lin <glin@suse.com>; edk2-devel@lists.01.org
>Subject: Re: [edk2] Fwd: StartImage with Secure Boot on Self-Signed App
>
>Is there a protocol with a simple to use function to check if the
>certificate of a PE binary image in memory is valid based on the
>machine keys installed?
>
>
>
>On Tue, Sep 12, 2017 at 12:32 AM, Gao, Liming <liming.gao@intel.com> wrote:
>> You can load and start the image based on PeCoffLib APIs in BasePeCoffLib
>instead of LoadImage() and StartImage() service.
>>
>>>-----Original Message-----
>>>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>>David F.
>>>Sent: Friday, September 08, 2017 11:34 PM
>>>To: Gary Lin <glin@suse.com>
>>>Cc: edk2-devel@lists.01.org
>>>Subject: Re: [edk2] Fwd: StartImage with Secure Boot on Self-Signed App
>>>
>>>Actually, even a StartImageEx() would be fine with parameter to allow
>options.
>>>
>>>On Thu, Sep 7, 2017 at 7:51 PM, David F. <df7729@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 <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
>>>_______________________________________________
>>>edk2-devel mailing list
>>>edk2-devel@lists.01.org
>>>https://lists.01.org/mailman/listinfo/edk2-devel