public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gao, Liming" <liming.gao@intel.com>
To: 'David F.' <df7729@gmail.com>, Gary Lin <glin@suse.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: StartImage with Secure Boot on Self-Signed App
Date: Tue, 12 Sep 2017 07:32:28 +0000	[thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E13A935@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CAGRSmLsRYdt5M9+nXZYX-sHP4chG5S2xz7X17XBgBuhm25ksGg@mail.gmail.com>

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


  reply	other threads:[~2017-09-12  7:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGRSmLuQ3prdU1D_PDfzZpWHdnMjQfzKzzU8EpvOMX4BWvcxQA@mail.gmail.com>
2017-09-07 20:00 ` StartImage with Secure Boot on Self-Signed App David F.
2017-09-08  2:11   ` Gary Lin
2017-09-08  2:51     ` David F.
2017-09-08 15:33       ` David F.
2017-09-12  7:32         ` Gao, Liming [this message]
2017-10-06  0:27           ` David F.
2017-10-09  6:56             ` Gao, Liming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A89E2EF3DFEDB4C8BFDE51014F606A14E13A935@SHSMSX104.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox