StartImage with Secure Boot on Self-Signed App

StartImage with Secure Boot on Self-Signed App

[David F.]

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.

TIA!!

Re: StartImage with Secure Boot on Self-Signed App

[Gary Lin]

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

Re: StartImage with Secure Boot on Self-Signed App

[David F.]

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

Re: StartImage with Secure Boot on Self-Signed App

[David F.]

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

Re: StartImage with Secure Boot on Self-Signed App

[Gao, Liming]

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

Re: StartImage with Secure Boot on Self-Signed App

[David F.]

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

Re: StartImage with Secure Boot on Self-Signed App

[Gao, Liming]

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